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CHAPTER  1 Introduction 


The  first  draft  of  the  Federal  Criteria  was  made  public  in  January  1993.  Several  thou- 
sand copies  of  the  Federal  Criteria  were  distributed  and  comments  on  this  first  draft 
were  received  between  January  and  April  of  1993.  Over  20,000  comments  were 
obtained  from  approximately  120  organizations.  These  organizations  represented 
defense  and  civil  government,  producer  and  procurer,  and  Neath  American  and  Euro- 
pean concerns.  The  purpose  of  the  Federal  Criteria  Workshop  that  was  sponsored  by  the 
National  Security  Agency  (NSA)  and  the  National  Institute  of  Standards  and  Tech- 
nology (NIST)  on  June  2nd  and  3rd  of  1993  was  to  address  these  comments.  All  those 
who  commented  on  the  first  draft  were  invited  to  attend.  The  workshop  consisted  of 
approximately  128  participants. 

In  the  opening  remarks  by  Stuart  Katzke  of  NIST  and  Robert  Scalzi  of  the  NSA,  the 
participants  were  informed  of  NIST’s  and  NSA’s  decision  to  work  with  the  Canadians 
and  Europeans  in  creating  a Common  Criteria  (see  Chapter  12).  The  members  of  the 
Common  Criteria  Editorial  Board  (CCEB)  are  Gene  Troy  (NIST),  Mario  Tinto  (NSA) 
Yvon  Klein  (France),  Chris  Kctley  (United  Kingdom),  Hartwig  Kreutz  (Germany),  and 
Paul  Cormier  (C^anada).  The  plans  for  the  CCEB  call  for  aligning  the  various  criteria 
(Trusted  Product  Evaluation  Criteria  (TCSEQ,  draft  Federal  Criteria,  the  Information 
Technology  Security  Evaluation  Criteria  (TTSEC),  and  the  Canadian  Trusted  Computer 
Product  Evaluation  Criteria  (CTCPEQ)  from  the  participating  countries.  All  the  CCEB 
members  attended  the  wcxkshop  and  were  available  for  any  questions  that  the  other 
participants  may  have  had. 

The  workshop  focused  on  specific  problems  that  were  identified  in  the  comments  but 
did  not  focus  on  a line-by-line  review  of  the  text  First,  global  issues  that  transcended 
the  various  areas  were  identified  in  a plenary  session.  Then,  the  global  issues,  as  well  as 
issues  from  each  of  the  separate  areas  (functional  requirements,  laotection  profiles, 
protection  profile  creation,  development  assurance,  evaluation  assurance,  CS  protection 
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profiles,  LP  protection  profiles,  and  issues  on  international  hamionization),  were 
discussed  in  st^oarate  breakout  sessions. 

The  purpose  of  this  proceeding  is  to  inform  the  Federal  Criteria  commentators  and  the 
wor^op  attendees  of  the  outcome  of  the  workshop.  Also,  this  proceeding  will  be  used 
as  a bluq}rint  for  updating  the  Federal  Criteria.  This  proceeding,  and  the  revised 
portions  of  the  draft  Federal  Criteria  contents,  will  be  the  two  principal  NIST/NSA 
inputs  to  the  CCEB.  Priliminaiy  plans  for  dealing  with  the  Federal  Criteria  comments 
are  included  in  this  document,  and  all  revisions  will  be  performed  under  the  direction  of 
NIST  and  the  NS  A. 

The  plans  for  revising  portions  of  the  draft  Federal  Criteria  are  still  being  determined. 
Note,  however,  that  all  the  topics  listed  in  the  Executive  Summary  in  the  next  section 
are  considered  to  be  important  and  will  be  input  to  the  CCEB.  After  specific  plans  for 
the  revision  are  finalized,  these  plans  will  be  made  available  to  all  those  who 
commented  on  and  attended  the  workshop  for  the  draft  Federal  Criteria. 

The  next  section  of  this  proceeding  gives  the  Executive  Summary.  This  is  followed  by 
the  moderator  reports  for  each  of  the  individual  breakout  sessions.  Then  the  plan  for 
future  work  on  the  Federal  Criteria,  which  is  a direct  outcome  of  the  comments  and  the 
workshop,  is  described.  The  appendix  gives  the  text  of  the  public  aimouncement  on  the 
Common  Criteria  effort 
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Executive  Summary 


The  one  issue  that  dominated  the  vast  majority  of  the  comments  and  workshop  partici- 
pants was  the  need  for  the  next  criteria  to  address  distributed  systems,  networks,  encryp- 
tion, and  PC  security.  These  areas  were  discussed  extensively  in  the  workshop  but  were 
not  specifically  addressed  since  there  was  no  text  in  the  present  draft  of  the  Federal 
Criteria  to  discuss,  and  since  a woiidng  group  had  already  be^  established  to  look  at 
these  issues.  However,  there  was  clearly  a mandate  from  the  commentators  and  from  the 
participants  that  the  document  is  severely  deficient  without  these  requirements  and  that 
any  future  criteria  would  not  be  friUy  useful  unless  these  issues  were  addressed. 

Also,  the  majority  of  the  participants  felt  that  there  were  several  elements  of  the  Federal 
Criteria  that  should  be  retained  in  the  progression  to  the  Common  Criteria,  especially 
the  notion  of  a protection  profile.  The  participants  liked  the  idea  of  creating  protection 
profiles  by  assembling  them  from  pre-defined  components.  However,  the  participants 
also  felt  that  the  make-up  of  the  components  themselves  should  be  revisited.  They  fell 
that  the  ordering  and  the  grouping  of  component  requirements  should  be  re-examined, 
and  that  the  interdependencies  among  the  various  components  and  of  particular  require- 
ments in  a single  component  should  be  made  more  clear. 

The  participants  also  felt  that  there  was  a problem  with  TCSEC  compatibility.  One  of 
the  main  goals  of  the  Federal  Criteria  wcxk  was  the  incorporation  of  the  TCSEC 
requirements.  This  was  not  only  in  recognition  of  TCSEC  technology  but  also  for  back- 
wtuds  compatibility  for  those  products  that  were  created  against  the  TCSEC.  The 
measure  of  this  incorporation  was  the  creation  of  protection  profiles  that  reflected  the 
TCSEC  classes  (with  CSl  addressing  the  TCSEC*s  C2  class,  and  LPl,  2, 3,  and  4 
addressing  Bl,  B2,  B3,  and  Al,  respectively).  However,  the  participants  felt  that  this 
goal  was  not  met.  They  felt  that  ndthu*  the  draft  Federal  Critoia  nor  the  IP  protection 
profiles  that  were  created  properly  represent  the  TCSEC  classes.  They  felt  that  the  LP 
protection  profiles  and  the  components  used  to  create  them  should  be  rewritten. 
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The  commentators  and  participants  also  felt  that  there  was  a need  for  the  Federal 
Criteria  to  go  beyond  the  scope  of  stand-alone  products.  They  also  felt  that  the  relation- 
ship  of  protection  profiles  to  security  targets  was  not  made  clear.  Although  not  specifi- 
cally addressed  in  the  Federal  Criteria,  many  commentators  and  participants  also  took 
die  opportunity  to  express  their  concerns  about  the  present  evaluation  process  and  the 
issue  of  muoial  recognition  of  international  evaluations  and  certificates,  especially  in 
light  of  the  Common  Criteria  effort.  There  were  also  concerns  expressed  on  how  protec- 
tion profiles  should  be  standardized,  registered,  and  vetted,  and  on  the  international 
vetting  of  protection  profiles. 
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Global  Issues 


Overview 


As  reflected  in  the  comments,  there  were  several  global  issues  that  transcended  discus- 
sion in  a single  area.  The  global  issues  session  was  created  to  reflect  these  comments. 
Four  global  issues  were  identified:  Federal  Criteria  benefits,  the  conc^t  of  ProtecticHi 
Profile,  the  concept  of  components,  atKl  products  vs.  systems.  All  of  these  topics  were 
introduced  in  a plenary  session,  and  then  discussed  individually  in  break  out  sessions  for 
the  rest  of  the  morning.  Then,  these  (and  other  topics)  were  discussed  in  a global  issue 
session  that  continued  through  the  afternoon.  It  should  be  noted  that  different  concerns 
were  expressed  in  the  morning  and  afternoon  groiq>s,  and  that  for  one  of  the  global 
issues  there  was  a divergence  of  opinion.  Where  this  divergence  occurred  will  be  indi- 
cated in  the  following  text 

Each  of  these  areas  are  discussed  below.  Note  that  no  differentiation  is  made  between 
what  the  morning  and  afternoon  groups  discussed  except  in  the  area  where  there  was  a 
divergence  of  views. 

It  should  also  be  noted  that  there  were  several  global  issues  in  the  comments  that  were 
not  addressed  in  this  session  even  though  most  reviewers  expressed  concern  about  these 
areas.  These  are:  networks,  distributed  systems,  low  end  PC  security,  and  encryption. 
There  was  an  agreement  that  these  issues  not  be  discussed  during  the  workshop  since 
there  was  no  intent  to  address  these  areas  in  this  particular  draft  and  since  there  was  no 
text  in  the  Federal  Criteria  on  which  to  base  this  discussicxi.  However,  these  issues  were 
brought  in  the  plenary  question  and  answer  session  and  many  in  the  audience 
expressed  the  opinion  that  these  areas  should  be  addressed. 
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Federal  Criteria  Benefits 


This  session  focused  on  a variety  of  subjects  and  these  topics  will  be  important  as  we 
move  to  the  Common  Criteria.  It  also  focused  on  several  flaws  of  the  Federal  Criteria, 
and  these  will  also  be  reflected  in  this  rqx)it. 

In  general,  the  group  agreed  that  the  following  were  Federal  Criteria  benefits: 

• The  unbundling  of  functional  requirements  from  each  other  and  from  assurances. 

• The  creation  of  protection  profiles  by  assembling  pre-defined  components  and  elabo- 
rating them  to  specific  product  targets. 

• The  explicit  sq)aration  of  documentation,  process,  and  evaluation  assurance. 

• Recognition  of  Ease  of  Use,  Physical  Protection,  and  Flaw  Remediation  (this  > 
thought  to  be  especially  important  to  retain)  as  requirements. 


Protection  Profiles 


There  was  a lot  of  discussion  on  the  notion  of  a protection  profil  e.  The  consensus  among 
both  groiq)s  was  that  we  need  the  notion  of  a protection  pio:>le,  and  that  protection 
profiles  describe  what  a consumer  wants  and  what  a vendor  should  build  towards. 
Protection  profiles  go  hand  in  hand  with  risk  analysis.  They  were  felt  to  be  a useful 
consumer's  tool  to  speU  out  requirements.  Protection  profiles  provide  the  basis  for 
market  driven  requirements,  ease  flexibility  in  presenting  requirements,  and  improve  the 
credibility  of  the  ITSEC's  notion  of '‘effectiveness.”  [The  IT^EC  defines  “effective- 
ness” in  security  evaluations  as  being  an  aspect  of  assurance  that  assesses  how  well  the 
iqjplied  security  functions  and  mechanisms  working  together  to  actually  satisfy  tiv 
security  requirements.]  Documenting  the  environmental  assumptions  in  protectio:: 
profiles  were  felt  to  be  a beneficial  feature. 

However,  several  concerns  were  expressed  about  protection  proBIc  s.  One  of  the  ques- 
tions asked  was.  What  is  the  value  of  a protection  profile  as  an  r.  va.yation  entity?  It  was 
felt  that  consumer  needs  do  not  have  to  be  evaluated,  but  that  the  notion  of  how  the 
produa  satisfies  those  needs  do.  It  was  felt  that  the  definition/purpose  of  what  is  a 
protection  profile  is  not  dear  in  the  Federal  Criteria.  The  group  came  to  the  conclusion 
that  protection  profiles  are  a “what”  definition,  i.e.,  that  protection  profiles  state  what  the 
functional  and  assurance  requirements  are,  and  a security  target  is  a “what”  and  “how” 
definition,  ix.,  that  security  targets  state  what  the  leqeirements  are  and  how  they  are 
being  met  for  a particular  product  The  group  also  fell  that  in  some  cases  products 
should  be  able  to  be  developed  without  a protection  profile  when,  for  example,  a unique 
produa  is  being  built,  or  when  a generalized  statement  of  requirements  is  not  needed. 

The  group  also  expressed  the  opinion  that  protection  profiles  facilitate  govenunents  and 
other  agencies  in  getting  their  security  requirements  in  front  of  vendors.  To  be  useful, 
protection  profile  creation  needs  to  be  market  driven.  The  user  groups  that  will  have  an 
imexest  in  creating  profiles  include  not  only  end-user  groups,  but  integration  contractors 
and  value-added  reseUers  as  well.  Vendor  market-research  groups  may  also  be  in  a good 
position  to  know  both  what  is  needed  and  what  is  feasible.  Thus,  even  though  profiles 
are  designed  to  express  user  needs,  vendors  may  also  become  actively  involved  If 
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similar  security  targets  continue  to  be  produced  and  used,  somecme  will  realize  the  value 
of  extracting  a common  protection  profile  from  them.  It  was  felt  that  in  the  long  run, 
security  targets  will  be  a source  of  protection  profiles. 

The  global  issues  group  felt  that  the  creation  of  protection  profiles  may  be  too  hard  for 
consumers  to  vet  even  though  consumers  have  needs  that  don’t  map  to  the  TCSEC.  The 
group  felt  that  protection  profiles  are  really  application  profiles  for  various  commercial 
industries,  e.g.,  financial,  telecommunications,  etc.,  but  did  not  feel  that  the  market  will 
create  these  protection  profiles  without  some  govenunent  intervention.  The  group  felt 
that  it  was  unrealistic  to  assume  that  consumers  will  “get  together”  to  create  protection 
profiles,  and  they  felt  that  the  government  (e.g.,  NIST,  Information  System  Security 
Association  (ISSA))  should  take  a leading  role  in  sponsoring  the  creation  of  protection 
profiles,  and  should  assemble  people  from  these  various  industries  for  the  purpose  of 
putting  these  profiles  together. 

There  were  also  many  concerns  with  how  many  protection  (xofiles  there  was  going  to 
be  and  what  mechanisms  or  controls  would  be  in  place  to  limit  the  number  of  protection 
profiles.  The  global  issues  group  felt  that  the  proliferation  of  protection  profiles  may  be 
self  constraining  because  of  the  number  of  resources  that  are  needed  to  create  the 
protection  profile.  Several  participants  expressed  concern  that  too  many  profiles  will 
produce  market  fragmentation,  thereby  undermining  a primary  motivation  for  distin- 
guishing between  profiles  and  security  targets  in  the  first  place.  The  protection  profile 
group  expressed  much  pessimism  on  actuaUy  accomplishing  control  The  problem  of 
controlling  the  proliferation  is  related  to  the  question  of  who  wUl  produce  profiles:  if 
their  creation  is  privately  funded,  they  may  be  registered  only  with  their  funding  organi- 
zation. It  was  felt  that  vendors  will  probably  aggregate  profiles  to  cover  more  than  one 
market  and  that  products  may  be  designed  to  simultaneously  satisfy  several  different 
profiles.  This  already  happens  for  products  that  are  simultaneously  evaluated  against  the 
C2  and  B1  TCSEC  clas^  Because  of  this,  it  may  be  appropriate  to  consider  profile 
composability  so  that  vendors,  evaluators,  and  consumers  can  better  appreciate  the 
implications  of  such  products. 

The  protection  profile  group  also  felt  that  accq)tance  vetting  could  be  performed  in  a 
decentralized  or  local  mode.  That  is,  there  could  be  local  registries  of  protection 
profiles,  and  also  a centralized  registry  of  profiles  that  can  be  used  to  coordinate  consis- 
tency or  to  allow  a vendor  to  gain  information  on  the  “largest  common  intersection  of 
protection  profiles." 

The  International  Standards  Organization  (ISO)  was  discussed  as  a possible  answer  to 
the  registradon  of  protecdon  profiles.  Unfortunately,  ISO  has  a reputadon  for  being 
slow  and  unoriginal  This  implies  that  for  profile  registradon  to  be  effecd  ve,  other  stan- 
dards bodies  must  be  involved.  The  NIST  FIPS  publicadons  could  provide  a more 
timely  U.S.  mechanism  for  registering  profiles,  at  the  expense  of  not  being  intemadonal. 
Registradon  issues  differ  for  government  and  nongovernment  profiles:  nadonal  profiles 
presenting  government  security  needs  make  more  sense  than  nadonal  profiles 
presenting  the  security  needs  of  a muldnadonal  industry  or  consumer  group.  The 
primary  purpose  of  protecdon  profile  registries  should  be  to  create  a sensible  market- 
place for  security  ideas  and  products,  as  opposed  to  enforcing  control  over  this  market 
Also,  as  past  evaluations  against  the  TCSEC  classes  have  shown,  the  TCSEC  require- 
ments change  continuously  under  interpretadon  by  evaluators.  Consequently,  a regis- 
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tered  profile  needs  to  include  points  of  contact  that  can  explain  the  needs  of  the  user 
group  that  produced  the  profile,  in  order  to  facilitate  useful  profile  interpretation.  Simi- 
larly, the  profile  registry  needs  to  include,  for  each  profile,  a legislative  history  of  how 
its  (unintended)  ambiguities  have  been  resolved. 

As  to  the  registration  of  functional  aiKl  assurance  packages,  one  participant  noted  that 
functional  requirements  are  more  marketable  than  assurance  requirements,  and 
consumers  tend  to  boy  assurance  only  under  duress.  This  suggests  that  there  might  be 
many  functionality  packages  but  relatively  few  assurance  packages,  with  most  assur- 
ance packages  emphasizing  straightforward  third-party  validation  of  vendor  claims. 

It  was  felt  that  the  vetting  process  will  be^  to  establish  the  ITSEC : notion  of  **correct- 
ness."  [The  ITSEC  defines  “correcmess”  in  security  evaluations  as  baing  the  presej^  a- 
tion  of  relevant  properties  between  successive  levels  of  representations.  Examples  n:' 
representations  could  be  top-level  functional  specifications,  detailed  design  specific;.'- 
tions,  or  an  actual  implementation.]  It  was  also  felt  that  vetters  need  to  have  enough 
authority  to  constrain  originators,  and  that  international  vetting  will  indirectly  alleviate 
concerns  about  export  licenses.  However,  the  Federal  Criteria  was  not  clear  abou-  the 
vetting  process  and  who  will  pay  for  the  vetting.  It  was  also  thought  that  a well- 
designed  centralized  registration  process  could  provide  cost-effective,  high  standards 
for  the  evaluation  of  protection  profiles.  Without  protection  profiles,  this  evaluation 
activity,  much  of  which  is  need^  for  the  evaluation  of  any  conforming  product,  would 
be  pefformed  by  many  indq)endent  laboratories  in  multiple  countries,  lliis  multiplicity 
could  result  in  toth  a lack  of  uniform  quality  and  duplication  of  effort  from  one  evalua- 
tion to  the  next 

It  was  also  felt  that  the  vetting  of  profiles  is  inherently  difficult  During  the  creation  of 
the  TCSEC,  vetting  of  the  evaluation  classes  involved  lots  of  arguing.  The  challenge  is 
to  provide  procedures  which  will  make  vetting  routine,  predictable,  and  well-under- 
stc^ 

As  to  the  issue  of  whether  there  will  be  too  many  protection  profiles,  the  group  felt  that 
this  will  not  happen  since  it  will  take  too  much  time  and  money  to  produce  one.  Market 
driven  is  an  important  concept  - the  government  should  only  ^ctate  what  the  security 
requirements  should  be  for  government  agencies,  not  dictate  to  vendors  what  the  secu- 
rity requirements  should  be  for  those  outside  of  the  government  The  protection  profile 
subgroup  felt  strongly  that  the  market  should  do  that  They  also  felt  that  profiles  that 
were  responded  to  frequently  (as  evidenced  by  having  products  created  against  them 
and  by  having  them  referenced  in  end-user  procurements)  would  be  the  ones  that  would 
last  Thus,  having  a large  number  of  profiles  was  deemed  not  too  important  This 
concept  reduces  the  need  for  government  participation  excqrt  as  a lo^  registry  and  as  a 
provider  of  coordination  services. 

As  to  the  question  of  whether  the  ITSEC  notion  of  a security  target  is  necessary  or  suffi- 
cient it  was  felt  that  both  profiles  and  security  targets  are  needed  because  they  serve 
different  complementary  purposes.  According  to  the  p^r  j-^oants,  the  most  significant 
difference  between  protection  profiles  and  security  ta.^c*„^  br  far,  is  the  fact  that 
consumer  groups  pttxiuce  profiles  whereas  vendors  proLiL-;:?  security  targets.  As  noted 
in  the  session  on  evaluation  assurance,  a security  target  includes  not  only  protection 
profile  information  but  additional  design  information  and  justification  that  the  design  is 
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correct  Security  targets  allow  flexibility  by  providing  a vehicle  for  a producer  to  specify 
security  objectives,  services,  and/or  mechanisms  that  exceed  those  found  an  existing 
profile.  For  example,  many  C2  systems  meet  the  B3  DiscreticMiary  Access  Control 
(DAQ  mechanism  requirements.  Both  groups  felt  that  having  a security  target  without 
having  a protection  profile  may  be  sufficient  in  cases  where  there  is  no  need  to  have  a 
general  set  of  requirements  that  several  vendors  can  built  to,  or  when  specifying  the 
security  aspects  of  a “one  shot"  system  or  product  prototype.  If  a single  unique  product 
is  being  built,  a security  target  is  all  that  is  needed  and  can  be  evaluated  against  The 
Federal  Criteria  needs  to  be  designed  in  such  a way  as  to  not  shut  out  good  security 
solutions.  Allowing  products  to  be  evaluated  solely  against  security  targets  provides  a 
means  of  addressing  this  concern.  Such  an  evaluation  can  encourage  a vendor  to  find  a 
solution  to  a user's  problem,  even  if  it  doesn’t  meet  an  existing  profile. 

The  participants  felt  that  the  existence  of  a security  target  is  always  necessary  in  that  it 
shows  how  a vendor  meets  a protection  profile  (when  one  exists),  shows  claims  of  what 
a vendor  provides  in  absence  of  a [Hofile,  and  shows  claims  of  what  a vendor  provides 
beyond  a profile.  It  was  also  felt  that  the  relaticxiship  of  a security  target  and  an  imple> 
mented  product  with  respect  to  the  evaluation  process  needs  further  clarification,  and 
that  the  structural  differences  between  protection  profiles  and  security  targets  also  needs 
further  clarification.  The  participants  concluded  that  when  a security  target  can  meet  a 
variety  of  protection  profiles,  we  may  have  the  best  marketing  value. 

The  Federal  Criteria  allows  but  does  not  require  the  creation  of  linear  profile  hierarchies 
(as  in  the  LPl  - LP4  series).  One  partici|>ant  observed  that  since  different  environments 
have  different  risks,  a linear  profile  hierarchy  suggests  that  all  risks  in  one  environment 
at  a lower  profile  hierarchy  are  included  in  some  uniformly  more  risky  environment  in  a 
higher  profile  hierarchy.  In  general,  it  was  felt  that  there  should  be  no  requirem^t  that 
protection  profiles  be  hierarchical  since  this  would  be  too  rigid,  but  a number  of  protec- 
tion profiles  could  be  considered  as  a family  or  hierarchy  to  give  the  industry  some  lati- 
tude for  improvement  It  was  also  felt  that  vendors  will  probably  aggregate  profiles  to 
cover  more  than  one  market 


Components 


There  were  a lot  of  issues  regarding  how  the  components  were  created  that  transcended 
what  type  of  components  (fuiKtional,  development  assurance,  or  evaluation  assurance) 
they  are,  and  the  component  group  (morning)  and  global  issues  session  (afternoon)  were 
asked  if  the  components  C*building  blocks*^  as  created  were  a useful  notion.  There  was 
a slight  divergence  in  opinion  between  the  two  groups.  The  component  group  was 
untuqTpy  with  the  existing  components  even  though  they  liked  the  concept  of  a common 
language  for  building  protection  profiles.  They  felt  that  the  Federal  Criteria  components 
as  they  are  now  stated  do  not  help  fHOtection  profile  writers  since  few  were  happy  with 
the  Fnleral  Criteria  profiles  and  two-thirds  of  the  existing  components  were  not  used  in 
these  profiles.  However,  the  global  session  group  liked  the  component  a;^7roach. 
However,  the  divergence  of  opinion  here  is  iK)t  that  large  since  the  global  issues  group 
also  agreed  that  all  the  components  should  be  re-examined. 

The  component  subgroup  was  not  sure  a “common"  component  language  was  possible 
since  there  is  no  “algebra  of  building  blocks",  that  is,  it  was  unclear  how  one  specifies 


FEDERAL  CRITERIA  WORKSHOP  PROCEEDINGS 


9 


Global  Issues 


component  requirements  at  a uniform  low  level  as  the  Federal  Critoia  attempts  and  how 
one  should  put  these  levels  back  together  as  a coherent  set  of  requirements.  Most  (but 
not  aU)  in  that  group  felt  that  many  functional  requirements  could  be  stated  by  utilizing 
an  algebra,  but  that  this  would  be  more  difficult  for  assurance  requirements.  Tlie  group 
generally  felt  that  we  as  a community  do  not  understand  the  ways  in  which  components 
can  be  merged  and  therefore  were  very  concerned  that  meaningless  (and  even  harmful) 
requirements  could  be  derived  from  what  seem  like  valid  components.  The  group  was 
not  ccxivinced  that  just  listing  the  dependencies  would  suffice  to  address  this  concern. 

The  component  group  also  felt  that  the  authors  should  state  the  basic  principles  behind 
the  components  that  were  builL  They  felt  that  if  these  criteria  were  not  based  on 
accepted  scientific  or  engineering  principles,  they  would  not  be  valid.  There  was  a 
strong  consensus  in  the  component  group  on  this  point  The  most  conservative  members 
in  the  component  group  felt  that  the  only  basic  principle  that  was  stated  in  the  Federal 
Criteria  was  that  of  the  reference  monitor,  and  that  this  was  not  satisfactory.  The  global 
issues  group  could  not  identify  any  basic  principle  beyond  the  ref^ence  monitor  that 
could  be  a justification  for  why  the  components  were  built  and  therefore  thought  the 
‘"basic  principle"  notion  would  not  help  in  building  the  components. 

Both  groups  agreed  that  the  ordering  and  grouping  of  requirements  in  the  components 
themselves  should  be  re-examined,  however,  the  component  group  was  more  critical 
about  the  component  content  and  felt  that  the  components  should  be  recast  The  compo- 
nent group  felt  that  value  added  "features"  should  not  be  ordered  (the  global  issues 
group  could  not  see  an  alternative  to  this),  but  that  other  requirements  should  be 
strongly  ordered  and  grouped  (mostly  the  assurance  components).  The  component 
group  also  felt  that  some  components  should  have  been  further  unbundled  (these  being 
mostly  the  functionality  components).  Also,  both  groups  thought  that  components  need 
not  be  of  like  ordering  or  granularity.  The  afternoon  group  thought  that  the  present  hier- 
archy with  increasing  levels  may  not  necessarily  create  a product  that  is  more  secure, 
and  agreed  with  the  morning  group  that  the  separation  of  requirements  into  different 
functional  levels  were  arbitrary  (e.g.,  the  auditing  component).  The  global  issues  group 
stated  that  component  requirements  should  noi  restrain  implementations.  The  global 
session  group  also  pointed  out  that  there  is  a problem  with  the  meaning  of  the  word 
"level"  in  and  of  itself.  For  example,  it  was  pointed  out  that  if  level  3 were  chosen 
across  the  board  for  a protection  profile,  you  would  not  come  out  with  something 
reasonable.  However,  as  opposed  to  the  component  group,  the  global  issues  group 
thought  that  the  ordering  and  grouping  should  be  re-examined  and  not  done  away  with. 

One  suggestion  was  made  in  the  component  group  for  re-doing  the  component  organi- 
zation. First,  the  basic  principles  should  be  documented.  Then,  the  currently  accepted 
industry  "bundles",  that  is,  all  the  criteria  that  is  know  as  accepted  (e.g.,  the  TCSEC, 
nSEC.  CTCPEC,  Minimum  Security  Functionality  Requirements  (MSFR),  Trusted 
Database  Interpretation  (TDI))  should  be  used  as  a starting  point  and  then  value  added 
features  should  be  added  unbundled  and  unordered.  Then,  the  authors  should  carefully 
examined  the  "new"  components  that  were  created.  However,  the  global  issues  session 
strongly  disagreed  with  this  suggestion.  They  felt  that  the  components  should  not  be  re- 
done, and  were  unsure  as  to  what  basic  principles  can  be  identified.  They  felt  very 
sQongly  that  the  TCSEC  "bundles"  should  not  be  used  as  a starting  point  because  the 
TCSEC  "bundles"  did  not  address  commercial  concerns.  They  also  felt  that  the  TCSEC 
did  not  iqiresent  all  basic  principles. 
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Both  groups  thought  that  the  inter-dependency  analysis  between  and  among  the  various 
requiremoits  in  the  components  should  be  better  spelled  out  since  it  will  be  difficult  for 
profile  writers  to  figure  them  out  for  themselves.  It  was  felt  that  for  each  “shall”  in  the 
Federal  Criteria  the  dq)endencies  should  be  identified  and  listed  with  each  component 
It  was  also  felt  that  the  Canadians  did  this  in  a more  straightforward  fashion  in  that  all 
their  dependencies  were  highlighted  in  boxes  with  each  component  and  that  we  may 
not  be  2^1e  to  mt^  out  all  the  dep^dencies. 

The  component  group  felt  that  new  or  modified  requirements  were  introduced  in  too 
great  a volume,  but  the  global  issues  group  thought  that  this  could  be  only  a document 
organization  problems.  The  component  group  also  felt  that  the  document  organization 
should  be  re-examined  and  the  Federal  Criteria  should  be  minimized.  They  also  would 
have  liked  to  have  seen  the  fimctional  packages.  The  component  group  also  felt  that  the 
Federal  Criteria  should  limit  the  requirement  statements  to  accepted  engineering  prac- 
tices rather  than  research  ideas  (but  not  exclude  adding  new  accepted  ideas),  but  the 
global  issues  groi^  didn't  see  how  this  statement  applied  to  the  Federal  Critoia  - the 
only  research  idea  that  they  could  remember  was  real  time  audit  alarms.  The  component 
group  identified  several  items  that  they  felt  were  not  well  accepted.  These  included  the 
requirements  for  both  functional  and  penetration  testing  as  defined  in  the  Federal 
CMteria  since  they  are  significantly  different  from  the  ITSEC  and  TCSEC,  the  require- 
ment for  using  “high-level  synchronization,”  the  allowance  for  layering  violation,  and 
the  use  of  multi-threaded  tasks  for  Trusted  Computing  Base  (TCB)  structuring. 


Products  vs.  Systems 


The  first  discussion  focused  on  the  different  approaches  to  “products”  and  “systems”  in 
the  ITSEC  and  FC.  Someone  from  the  audience  stated  that  the  Federal  Criteria  is  only 
applicable  to  a **product,”  while  the  ITSEC  was  applicable  to  both  “products”  and 
“systems.”  [The  ITSEC  defines  a “product”  as  being  a package  of  IT  software  and/or 
hardware  that  provides  functionality  designed  for  use  or  incorporation  within  a multi- 
plicity of  systems.  It  defines  an  FT  “system”  as  being  a specific  IT  installation  with  a 
particular  purpose  and  (^rational  envirotunenL] 

Part  of  the  problem  is  semantic.  The  definitions  appear  to  be  overloaded.  “Systems” 
appears  to  refer  to  both  actual  environments  of  use  as  well  as  assemblies  of  products. 
The  definitions  also  seem  to  be  dependent  on  the  observers  viewpoint  A supplier  may 
be  a “system  integrator”  who  employs  “products”  to  produce  a “system.”  But  to  the 
integrator's  customers,  the  resultant  integration  may  be  a '‘product”  offered  for  sale. 

Some  people  thought  that  additional  concepts  existed  between  '‘products”  and 
“systems.”  Others  thought  that  the  problems  were  all  in  the  semantics. 

Next,  the  group  addressed  the  re-use  of  “product”  evaluations  when  the  “products”  are 
integrated  into  “systems”  or  larger  products.  The  consensus  was  that  the  “product”  eval- 
uation produced  by  the  existing  Trusted  Product  Evaluation  Process  (TPEP)  are  not  re- 
usable. The  publisiied  evaluation  reports  zppcai  to  be  designed  as  final  reports,  not  as 
intermediary  vehicles  for  conveying  information  for  subsequent  re-use.  For  example, 
detail  and  proprietary  information  are  excluded.  Limited  re-use  might  be  possible  with 
respect  to  correcdveness,  but  only  with  many  caveats.  A need  was  expressed  for  a 
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rigorous  methodology,  referred  to  as  an  algebra,  for  combining  various  evaluation 
results. 

On  a positive  note,  they  felt  that  the  knowledge  gained  from  looking  at  previous  evalua- 
tion results  were  useful  from  a social  point  of  view  in  that  it  gave  the  reader  some 
knowledge  as  to  who  performed  the  evaluation  and  how  much  they  could  be  relied 
upon. 

The  combination  of  several  products  was  referred  to  as  composition.  It  was  the  group 
consensus  that  composition  depends  on  architecture,  design,  and  intoiace  specifica- 
tions. Without  specifications  for  interfacing  security-relevant  parameters  between  prod- 
ucts, composabUity  win  be  difficult  and  re-use  of  evaluation  results  next  to  impossible. 
Security  interface  specifications  are  probably  the  key  to  evaluation  re-use. 

The  majority  of  this  groi^  thought  that  it  is  practical  to  specify  generic  criteria  that 
could  be  used  for  either  products  or  systems. 


Miscellaneous  Issues 


Several  other  points  were  brought  up  in  the  global  issues  session.  These  are  listed 
below. 

Other  Federal  Criteria  Benefits 

• The  flexibility  found  in  both  the  functionality  and  assurance  requirements  should  be 
preserved. 

• Ease  of  **Secure*'  Use  (it  was  felt  that  the  component  tide  **Ease  of  Use**  was  not 
descr^dve  enough)  is  an  important  security  concern  and  should  not  be  deleted. 

• The  System  Entry  component  was  also  felt  to  be  an  important  security  concern  that 
should  not  be  deleted. 

• The  commercial  protection  profiles  were  thought  to  be  a good  start 

• The  notion  of  safe  defaults  should  be  preserved. 

Other  Federal  Criteria  Concerns 

Objective  measures:  There  was  a great  deal  of  discussion  by  the  commercial  vendors 
that  objecdve  measures  may  not  be  necessarily  useful  to  the  customer  and  that  the 
Federal  Criteria  has  to  strike  a balance  between  sdcldng  to  measurable  requirements  vs. 
making  value  judgements  (which  can  be  product  differentiators). 

Flaw  Remediation:  In  general,  the  global  issues  group  liki^<  Lhe  Flaw  Remediation 
component,  but  some  commercial  vendors  where  concerned  ti^t  how  flaw  remediation 
was  addressed  may  dq)end  on  the  severity  of  the  flaw  and  that  the  issue  may  be  “who  do 
you  tell  what  to  wfaerL**  They  also  felt  that  they  wanted  the  freedom  to  tell  a customer  to 
ipply  the  fix  wi:^  revealing  what  the  particular  problem  is  (for  security  reasons)  and 
that  this  was  no;  iptUed  out  in  the  Fbderal  Criteria.  Also,  r/ow  one  prevents  the  intro- 
duction of  fiaw^  during  flaw  remediation  should  be  addrei^sed. 
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Development  and  Evaluation  Assurance:  The  group  felt  that  the  separation  of  evalua- 
ticxi  and  development  assurance  requirements  as  now  found  in  the  Federal  Criteria  may 
not  be  useful. 

Evaluation  process:  The  group  was  not  happy  with  the  evaluation  process  as  it  now 
exists  and  felt  that  the  evaluation  process  is  a ten  year  experiment  that  has  failed.  It  was 
pointed  out  that  in  Europe  the  evaluations  of  products  only  occur  when  the  customer 
demands  it,  and  the  Federal  Criteria  in  and  of  itself  has  value  even  if  no  evaluaticms  are 
ever  dcxie  against  it  Some  commercial  vendors  stated  that  “designed  to  meet”  has  some 
relevance  to  the  consumer,  although  others  stated  that  this  phrase  could  just  as  easily  be 
used  to  mislead  the  consumer.  However,  the  protection  profile  group  also  felt  that  there 
needs  to  be  some  way  of  encouraging  truth  in  advertising;  vendors  too  often  have  prod- 
ucts evaluated  in  unusable  configurations,  thereby  defeating  the  whole  purpose  of  the 
evaluation  process.  This  might  be  done  via  constraints  cmi  the  vetting  of  profiles  and  the 
evaluation  of  security  targets.  One  light  hearted  suggestion  was  for  the  government  to 
copyright  profile  names,  requiring  that  they  not  be  misused,  just  as  the  Ada  Joint 
Program  Office  copyrighted  the  use  of  “Ada.” 

Rating  Maintenance  Phase  (RAMP):  There  was  a concern  that  the  RAMP  process 
was  not  addressed  in  the  Federal  Criteria. 
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Initial  Topic  Issues 


Based  on  analysis  of  the  comments  to  the  Functional  Requirements  the  following  set  of 
issues  were  presented  for  discussion.  Whenever  possible,  people  who  made  insightful 
comments  were  invited  to  present  their  positions. 

• Precision  in  Tenninology 

• Identification  and  Authentication 

• Access  Control 

• Availability  & Fault  Tolerance 

• Policy  Neutral  Criteria 

• TCB  & Reference  Monitor  Focus 

• Integrity 

• Open-Ended  Criteria 

• Issues  from  the  attendees 

The  ground  rules  for  discussion  were  to  focus  on  philosophy  & high-level  issues.  Word- 
smithing  was  to  be  handled  by  the  written  comments.  The  objective  of  the  workshop 
was  to  seek  guidance  and  direction.  Multiple  options  were  considered  useful,  especially 
if  statistical  indicators  such  as  distribution  of  (pinions  and  variance  were  captured. 

Precision  In  Terminology 

Martha  Branstad  of  Trusted  Information  Systems  presented  issues  concerning  precision 
in  tenninology.  She  emphasized  that  the  Federal  Criteria  must  be  meaningful  and  under- 
standable. Her  focus  was  on  arriving  at  a definition  of  security.  She  quoted  Dan  Sterne's 
definition  of  a security  policy  objective  as  **A  statement  of  intent  to  protect  an  identified 


FEDERAL  CRITERtA  WORKSHOP  PROCEEDINGS 


15 


Functional  Requirements 


resource  from  unauthorized  use**  and  emphasized  that  security  is  not  synonymous  with 
correcmess. 

The  ensuing  discussion  surfaced  several  inccxnpatible  positions  concerning  definitions 
of  information  security.  The  pragmatic  position  was  that  information  security  encom- 
passes whatever  activities  are  conducted  by  people  whose  function  is  to  support  infor- 
mation security.  The  theoretical  position  was  that  information  security  consisted  of 
those  objectives  and  controls  that  could  be  supported  by  a single  technological  mecha- 
nism, namely  the  reference  monitor.  It  was  also  observed  that  just  because  a concern  is 
important,  or  even  critical,  doesn't  make  it  part  of  security.  It  was  suggested  that 
combining  too  many  concerns  under  the  rubric  of  information  security  dilutes  the  focus. 

Identification  and  Authentication 

Presentations  on  Identification  and  Authentication  were  made  by  Russell  Davis  of  PRC 
and  Robert  Bosen  of  Enigma  Logic.  Both  their  presentations  and  the  discussion  focused 
on  passwords.  Overall,  they  felt  that  the  FC  should  not  specify  implementation  mecha- 
nisms. The  Federal  Criteria  should  lead  but  not  mandate  the  way.” 

Although  networking  issues  had  been  declared  out  of  bounds  during  the  opening 
plenary  session,  there  was  general  consensus  that  plain  text  nansmission  of  passwords 
was  too  important  a vulnerability  to  ignore.  Networic  monitoring  hardware  and  software 
makes  it  very  easy  for  passwords  to  be  compromised.  Users  without  private  offices  were 
identified  as  being  vulnerable  to  password  compromise. 

In  light  of  these  well-known  vulnerabilities  of  passwords,  there  was  considerable  senti- 
ment that  too  much  emphasis  was  placed  on  password  selection  and  generalization. 
Lack  of  human  engineering  was  also  cited  as  a problem,  especially  when  more  than  one 
password  must  be  memorized  by  a user  with  multiple  computer  systons  and  accounts. 
Removal  of  password  guidance  to  a separate  document  was  strongly  advocated. 

The  absence  of  any  material  addressing  authentication  by  means  other  than  memorized 
passwords  was  considered  a gross  oversight  Various  technologies  were  mentioned, 
including  smart  cards,  trusted  path,  and  encryption.  Biometrics  were  not  mentioned 
during  the  session. 

Access  Control 

Joe  Sirrianni  of  the  Air  Force  Cryptologic  Support  Center  and  Ravi  Sandhu  of  George 
Mason  University  presented  their  views  on  Access  Control.  They  felt  that  Access 
Control  is  the  single  most  important  issue,  perhaps  after  Identification  and  Authentica- 
tion. They  admonished  the  working  group  to  start  afresh  and  write  clearly.  In  particular, 
they  pointed  out  that  Access  Control  is  a mechanism  and  that  it  was  unwise  to  force  a 
policy  legacy  from  the  TCSEC  onto  the  new  criteria,  suggesting  that  the  TCSEC  should 
be  preserved  as  a protection  profile  and  not  as  Access  Control  Functional  components. 
See  the  discussion  on  policy  neutralin'^  for  more  on  this  point  They  suggested  that  the 
granularity  of  the  Access  Control  component  is  too  coarse;  it  shoidd  be  subdivided. 
Questions  were  raised  about  the  validity  of  comparing  Access  Control  ratings  between 
two  products  or  profiles.  For  example,  CS2  and  CSS  contain  dissimilar  extensions  to  the 
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AC-2  component.  Separate  rating  of  Access  Control  components  according  to  the 
policy  enforced  was  suggested. 

Availability  & Fault  Tolerance 

Presentations  on  Availability  & Fault  Tolerance  were  made  by  Vic  Marshall  of  Booz, 
Allen  & Hamilton  and  Holly  Hosmer  of  Data  Security.  They  pointed  out  the  need  for 
woriced  general-purpose  examples  to  aid  in  assessing  these  attributes.  There  is  no  agree- 
ment on  what  any  of  this  means.  It  is  an  application-dependent  issue;  for  example, 
prevention  of  denial  of  sovice  in  one  application  inappropriately  denies  service  in 
another. 

Availability  covers  much  more  than  security;  availability  is  not  a security  service, 
according  to  GOSIP.  Denial  of  service  is  only  one  type  of  threat  Resource  allocation  is 
a duty  of  the  system  administrator.  Fault  management  is  not  security  management  The 
TCB  should  be  expanded  to  provide  these  services.  The  components  of  availability  are 
containment,  fault  tolerance,  robustness,  and  recovery.  Customers  take  a holistic  view; 
so  should  the  FC. 

Policy  Neutral  Criteria 

There  were  several  comments  that  the  FC  failed  to  meet  the  stated  goal  of  policy 
neutrality.  Policy  is  implied  in  many  places.  There  is  no  technical  rationale  and  justifica- 
tions for  the  statements  about  policy  neutrality.  We  know  how  to  build  things  that 
enforce  some  confidentiality  policies;  we  do  not  know  how  to  build  things  to  enforce 
availability  and  integrity  policies.  The  fundamental  mechanisms  that  work  for  one 
policy  do  not  work  for  the  others.  When  one  starts  requiring  policy,  one  restricts  innova- 
tion in  design  of  policy.  The  requirement  to  define  a policy  was  not  stated  clearly  or 
obviously. 

The  components  are  replete  with  policy.  For  example.  System  Entry  is  a policy  issue. 
*The  TCB  shall  dppear  to  perform  the  entire  user  authentication  procedure  even  if  the 
user  identification  entered  is  invalid”  is  an  I&A  policy  issue.  Policy  is  ANYTHING 
which  resuicts  the  methods  by  which  the  vendor  can  meet  the  requirements  stipulated  in 
a given  functionality  or  assurance  component 

Discretionary  Access  Control  (DAC)  assumes  that  the  individual  usct  is  the  funda- 
mental policy  attribute  on  which  the  controls  are  based.  This  does  not  have  to  be  so;  for 
many  commercial  uses,  it  should  not  be  so.  A requirement  for  fail-safe  default  parame- 
ters is  logically  impossible  because  definition  of  “safe”  is  policy  dependent  in  a very 
complex  way.  The  FC  appears  to  prevent  a policy  which  preserves  the  anonymity  of 
users. 


TCB  & Reference  Monitor  Focus 

A presentation  concerning  focus  on  the  TCB  and  Reference  Monitor  was  made  by  Sven 
Lorsson  of  the  Swedish  Defense.  Considerable  polarization  focused  on  TCB  & Refer- 
ence Monitor  concq>ts.  (At  one  extreme  was  the  position  that  the  FC  exhibits  a lack  of 
underlying  principles  from  “basic  science.”  This  was  understood  to  refer  to  the  Refer- 
ence Monitor  concq)t  as  the  principle  basis  for  secrecy  and  integrity.  Rigorous  mathe- 
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matics  has  been  applied  ic<  ihe  Reference  Monitor.)  The  FC  omits  the  partitioned  TCB, 
balanced  assurance,  and  TCB  subsets.  From  this  viewpoint,  the  FC  fails  to  protect 
against  deliberate  acts  of  a hostile  opponent;  rather  it  relies  on  “penetrate  and  patch.** 

The  contrasting  position  holds  that  the  TCB  and  Reference  Monitor  are  merely  a design 
concept.  They  rqjresent  one  way  to  design  an  operating  system  and  that  design  concepts 
should  be  covered  under  assurance,  NOT  functionality.  A question  was  raised  as  to 
whether  the  Reference  Monitor  concept  is  still  suitable  when  information  flows  from 
one  computer  system  to  another  in  a network.  In  this  instance  there  is  no  single  state  or 
single  domain  and  security  information  needed  by  the  Reference  Monitor  is  not  strictly 
under  its  own  control.  Software  that  implonents  any  functional  securi^^  requirement  is 
part  of  the  TCB. 

Somewhat  between  the  extremes  are  observations  that  a TCB  should  really  protect 
against  malicious  software.  The  TCB  sometimes  is  not  distinct  software  within  a 
product  The  TCB  may  not  be  identifiable  or  iiunimal;  it  is  often  the  entire  product. 
Appendix  B in  the  Federal  Criteria,  “The  Reference  Monitor  Concept,"  does  not  accu- 
rately reflect  the  notion  of  the  Reference  Monitor. 

Integrity 

Gary  Grossman  of  Cordant  made  a presentation  on  integrity,  introducing  the  concept  of 
integrity  problems  which  do  not  involve  a subjea  or  access  control  Examples  include 
hardware  noise  and  component  failure,  software  bugs  and  viruses,  and  errors  by  privi- 
leged users. 

Considerable  discussion  focused  on  the  question  as  to  whether  the  TCB  concept  applies 
to  integrity.  The  PC  does  not  provide  for  the  notion  of  an  integrity  TCB.  One  position  is 
that  an  integrity  TCB  is  significantly  different  from  a traditional  confidentiality  TCB.  It 
necessarily  includes  application-  specific  components  and  well-formed  transactions. 
Access  control  solves  a very  small  (albeit  important)  aspect  of  the  integrity  problem. 

There  is  no  mention  in  the  PC  of  how  security  management  affects  integrity. 

Open-ended  Crtteria 

The  PC  and  all  the  components  are  stated  to  be  extensible,  but  most  of  the  comments 
appear  to  assume  that  the  components  presented  in  the  FC  constitute  the  entire  seL  Why 
is  the  message  not  getting  across? 

Structure  of  Requirements 


Sentiment  was  expressed  that  many  of  the  components  in  Chapter  4 of  the  Federal 
Criteria  have  been  randomly  put  into  a hierarchy.  The  structure  may  be  related  to  the 
policy  that  a particular  system  implements  and/or  the  type  of  threat  addressed.  Since  the 
relative  importance  of  threats  will  vary  among  environments,  a hierarchy  is  not  appro- 
priate. 
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Summary  of  Functional  Requirements  Discussions 


The  discussicHis  concerning  functional  requirements  are  summarized  in  this  section, 
grouped  into  the  following  areas. 

• Defining  the  scope  of  security 

• Integrity 

• Policy  Indq)endence 

• Identification  and  Authentication 

• TCSEC  Compatibility 

• Access  Control 

Defining  the  Scope  of  Security 

Definition  of  the  scope  of  “security”  is  a management  decision.  Two  alternatives  are: 

• Accept  the  current  usage  of  the  term.  All  work  done  by  people  who  are  called  secu- 
rity professionals  should  be  accepted  as  “security  work.”  This  includes  support  for 
availability,  recovery,  and  fault  tolerance. 

• Taxonomize  according  to  a fundamental  technology  basis.  Security  should  be  those 
activides  that  can  be  supported  by  a Reference  Monitor.  Availability,  recovery,  and 
fault  tolerance  are  excluded. 

Keeping  disciplines  separate  does  not  diminish  their  importance.  Just  because  a problem 
is  important  or  even  crucial  doesn't  make  it  security.  Specialists  in  various  disciplines 
can  work  together. 

Integrity 

Even  after  many  years  of  work,  there  is  no  agreement  on  definidon.  Perhaps  the  FC 
should  focus  on  specific  protecdon  policies,  such  as  protecdon  against  unauthorized  or 
undesirable  modificadon,  without  trying  to  achieve  a comprehensive  defiiudon  of 
“integrity.”  That  is,  get  on  with  the  work  and  stop  arguing  on  what  name  to  call  iL  There 
appears  to  be  insufficient  recognidon  that  protecdon  against  unauthorized  or  undesirable 
modificadon  is  considerably  different  in  malicious  and  non>malicious  environments. 

The  implicadons  of  applying  the  TCB  and  Reference  Monitor  concq)ts  to  “integrity” 
need  to  be  studied.  It  is  unclear  whether  an  integrity  TCB  is  a valid  concept  compadble 
with  the  concept  of  a confidentiality  TCB.  In  many  cases  the  integrity  policy  is  in  the 
applicadon.  Extending  the  TCB  and  Reference  Monitor  to  encompass  applicadons 
needs  further  study.  In  many  cases  the  applicadon  is  specific  to  a system;  in  these  cases, 
integrity  cannot  be  addressed  in  a product,  only  in  a system. 

Further  understanding  of  the  interacdon  of  multiple  policies  in  operating  systems  and 
applicadons  is  needed.  New  models  may  help.  The  terms  “maiKlatory”  and  “discre- 
donary”  do  not  appear  to  be  rich  enough  to  characterize  the  integrity  concerns. 
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Policy  Independence 

Protection  profiles  should  include  polices,  but  components  should  not  have  a policy 
bias.  In  many  cases  there  may  be  a one-to-one  relationship  between  a policy  and  a 
component.  This  relationship  should  be  explained.  Alternative  components  should  be 
provided  for  other  policies.  In  some  cases  the  policies,  and  the  corresponding  compo- 
nents, may  be  diametrically  opposed.  The  set  of  available  components  should  be  as 
inclusive  as  possible. 

There  are  many  policy  assumptions  and  biases  throughout  the  PC.  For  example.  Identi- 
fication and  Authentication,  System  Entry,  and  Accountability  are  all  policies.  Many 
people  appear  to  find  it  difficult  to  acknowledge  an  unfamiliar  policy;  they  tend  to  think 
that  the  policy  they  are  familiar  with  is  **right**  and  the  unfamiliar  is  *'wrong.*’ 

Identification  and  Authentication 

Identifi^tion  and  authentication  must  be  sonengthened.  There  is  too  much  emphasis  on 
passwt^,  especially  when  privacy  is  not  assmed  by  physical  means.  Passwords  alone 
are  insufficient  in  many  cases;  provision  should  be  explicit  for  alternative  technology. 

A common  authentication  approach  is  needed.  The  PC  should  not  sp»:ify  mechanisms. 
The  PC  should  lead,  not  mandate,  the  way. 

TCSEC  Compatibility 

The  TCSEC  should  be  preserved  as  protection  profiles,  not  as  fimcfional  components. 
An  open  question  remains  concerning  incorporaiion  of  knowledge  gained,  and  require- 
ments changes  made,  since  publication  of  the  TCSEC. 

Access  Control 

Access  control  is  a mechanism  that  can  enforce  many  different  policies.  The  tendency  to 
embed  policy  in  access  control  should  be  resisted.  Role-based  access  control  is  not  well 
understood.  The  interaction  between  role  policy  and  mechanisms  is  hard  to  unravel. 
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introduction 


This  session  addresses  those  comments  pertaining  to  evaluation  assurance  and  evalua- 
tion processes.  In  general,  this  pertains  to  Chapter  6 of  the  Federal  Criteria  (FQ  but 
some  issues  will  overls^  with  those  of  other  chapters,  and  with  general  issues  to  be 
considered  by  the  drafters  of  the  PC. 

Session  Preparation 


To  stimulate  discussions  during  the  session,  an  initial  list  of  key  discussion  topics  was 
constructed  from  the  written  comments  provided  by  the  FC  reviewers.  These  are 
outlined  below: 

• Role  of  Evaluation-Assurance  Requirements.  From  the  comments,  the  proper  role  of 
evaluation  assurance  requirements  in  the  FC  does  not  seem  be  fully  understood  or 
agreed  upon.  This  prompted  such  basic  questions  as  the  following:  Do  we  need 
Evaluation  Assurance  Requirements?  Should  they  be  a sqiarate  set  of  requirements? 
Should  they  be  included  in  protection  profiles? 

• Evaluation  Processes  and  Organizations.  Some  reviewers  thought  that  Ch^ter  6 
should  have  said  more  about  evaluation  processes  and  organizations  and  should  have 
given  mOTe  explicit  advice  on  how  to  handle  subjective  aspects  of  evaluations.  How 
should  the  evolving  FC  incorporate  these  thoughts? 

• Need  for  Additional  Material.  Some  reviewers  felt  that  Chapter  6 was  insufficient 
with  respect  to  current  technologies  and  assurance  techniques.  Others  thought  it 
went  too  far  in  presenting  options  that  have  not  been  tested  in  existing  evaluations. 
What  should  be  the  form  and  content  of  evaluation  requirements?  What  should 
constrain  the  evaluation  requirements? 
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• Inter-chapter  dependencies.  These  comments  were  particularly  troubling  with 
respect  to  Chapter  6.  Some  reviewers  recommended  explicitly  mentioning  all  depen- 
dencies on  previous  chapters.  Others  recommended  that  the  requirements  be  recast 
in  more  general  form  in  order  to  eliminate  unnecessary  dependencies.  How  should 
dq)endency  linkages  be  addressed?  Again,  what  should  be  the  form  of  evaluation 
requirements? 

• Miscellaneous  Evaluation-Specific  Issues.  Some  reviewers  also  thought  that  the 
evaluation  methods  presented  in  Chapter  6: 

- assume  an  evaluation  process  that  is  not  appropriately  tied  to  product  develop- 
ment cycles. 

- do  not  provide  evaluators  with  enough  (subjective)  latitude  with  respect  to  au- 
thority for  evaluation  progress. 

- lack  clarity,  objectivity,  and  simplicity. 

- fail  to  provide  explicit  objective  measures  of  what  counts  for  success. 

- do  not  properly  meld  evaluations  for  Protection  Profiles,  Security  Targets,  and 
Products. 


Session  Overview  and  General  Observations 


The  session  began  with  an  introductory  briefing  on  the  purpose  and  scope  of  the  session 
tasking.  The  moderators  provided  background  on  how  the  current  evaluation  ch^ter 
evolved.  This  included  working  group  discussions  on  whether  the  draft  FC  should 
include; 

1.  evaluation  authorities  and  oigatuzational  structures  (e.g..  Trust  Technology  Assess- 
ment Program  (TTAIO). 

2.  q)ecific  forms  of  an  evaluation  process  (e.g..  Trusted  Produa  Evaluation  Program 
(TFEP)  Process  Improvement  Team), 

3.  qualifications  of  evaluators, 

4.  specific  evaluation  techniques  and  methods,  and/or 

5.  evaluation  metrics. 

It  was  explained  that  it  had  been  decided  that  the  first  three  items  this  list  were 
deemed  to  be  out-of-scope  because  they  are  essentially  business,  a -sions  and  could 
change.  Therefore  only  the  last  two  items  were  addressed  in  the  FC.  it  was  also 
explained  that  this  caused  many  reviewers  to  see  this  chapter  as  being  incomplete. 

Finally,  the  moderator  introduction  included  the  presentation  of  the  above  “key**  ques- 
tions prompted  by  a review  of  all  the  public  commentary  on  evaluation  assurance  in  the 
draft  FC. 

This  irutial  context  set  a constructive  tone  and  allowed  the  participatus  to  respond  with 
positive  direction  and  comments.  The  essentials  of  the  session  discussions  are  captured 
below. 


While  the  session  was  lightly  attended,  the  scsdon  had  a good  cross-section  of  interests 
and  opiiuons.  The  participants  consisted  of  approximately  9 individuals  representing 
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vendors,  accreditors,  integrators,  European  CCEB,  National  Computer  Security  Center 
(NCSC),  National  Security  Agency  (NS  A),  and  evaluators.  Their  participation  was 
generally  lively  and  discussion  extended  well  beyond  the  allowed  session  timeframe. 

With  respect  to  woiicshop  consensus,  the  size  of  this  group  precludes  any  results  of  this 
session  ^‘speaking  for  the  workshop.”  However,  the  items  (key  questions)  used  to  stimu- 
late the  discussions  were  developed  from  the  “consensus”  of  the  written  comments 
produced  by  the  FC  reviewers  on  assurances  in  general  and  Ch^ter  6 sp>ecifically. 
Although  directly  impacting  Chapter  6,  the  “guidaiKe”  themes  that  resulted  from  these 
discussions  became  more  global  in  nature  than  specifically  addressing  Chapter  6. 
Perhaps  this  is  because  of  the  “back  to  basics”  approach  taken  by  the  group.  The  single 
major  conclusion  of  the  discussions  was  that  evaluation  assurance  should  take  a 
different  form.  This  is  discussed  in  more  detail  below.  There  was  simply  little  else  to  say 
to  directly  improve  any  material  currently  written  in  Chapter  6 until  the  basics  were 
covered. 
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Role  of  Evaluation  Assurance  Requirements 

In  response  to  the  question,  “Do  we  need  evaluation  assurance  requirements?,”  the 
general  opinion  of  the  participants  was  “globalized”  to  state  that  evaluation  criteria 
should  be  the  central  aspea  of  the  FC.  That  is,  the  document  should  be  product  and/or 
system  irfosec  evaluation  criteria.  It  does  not  quite  achieve  that  now.  It  should  provide 
appropriate  product  and/or  system  evaluation  perspectives.  The  essential  themes  of  such 
an  evaluation  criteria  not  only  should  be  telling  the  vendors  what  to  build  into  their 
products  (the  FC  does  this),  but  telling  them  what  counts  for  success.  This  means 
detailing  what  evaluators  must  do  to  assure  that  the  product  actually  meets  the  success 
criterion  and  telling  venders  and  evaluators  both  what  and  how  they  should  document 
and  r^rt  the  achievement  of  a successful  evaluation  in  a meaningful  way.  If  the  Protec- 
tion Profile  concept  is  to  prove  adequate,  it  must  provide  such  criteria.  The  components 
in  Chapter  6 do  not  now  support  this  “global”  set  of  evaluation  requirements. 

In  arriving  at  guidance,  the  discussion  evolved  around  three  audiences  for  evaluation 
criteria:  accreditors  & certifiers,  who  must  use  the  output  of  product  evaluations;  evalu- 
ators, who  must  assess  both  the  product  and  the  processes  that  produced  it;  and  vendors, 
who  must  be  responsive  both  in  terms  of  their  product  and  their  (development  assur- 
ance) processes  to  the  criteria  requirements.  It  was  proposed  that  the  FC  should  start 
with  the  requirements  of  the  system  accreditors  & certifiers  to  derive  what  is  necessary 
with  respect  to  reporting  produa  information  and  conveying  the  assurance  gained  by 
product  evaluation  and  vendor  product  development  The  FC  authors  should  then  back 
into  what  must  be  done  to  produce  that  information  and  assurance.  Additionally,  to 
avoid  non-useful  products,  the  criteria  must  take  a system’s  view  with  respect  to  product 
use  and  secure  extensibility.  Finally,  to  ensure  that  appropriate  products  can  be  acquired 
for  systems,  there  needs  to  be  an  explicit  tie-in  with  government  acquisition  regulations. 
Evaluation  requirements  should  be  written  in  such  a way  that  they  can  be  used  in 
procurements,  so  that  a statement  of  work  (SOW)  can  make  use  of  them  (i.e.,  the  Data 
Item  Descriptions  (DID)  should  be  visible  in,  or  capable  of  being  assembled  fix)m,  the 
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product  criteria).  Current  criteria  cannot  be  so  used  because  it  is  too  vague — thus,  many 
of  the  requirements  are  not  contractually  enforceable. 

Perhaps  most  importantly,  the  discussion  of  the  issue  of  who  are  the  intended  recipients 
of  product  evaluation  information  raised  the  issue  of  the  proper  specification  of  product 
evaluation  output  (e.g.,  the  Final  Evaluation  Report)  which  in  uun  could  lead  to  changes 
in  the  evaluation  process  or  to  changes  in  trusted  product  criteria.  Here  the  discussion 
indicated  that  expression  of  a trusted  product  must  contain  some  system  implications 
(e.g.,  the  proper  way  to  securely  interface  the  product  to  communications  products 
which  are  al»  trust^;  the  way  to  extend  the  product's  TCB).  The  FC  must  ensure  that 
interface  and  extension  issues  are  properly  dealt  with  in  evaluations. 

For  example,  accreditors  are  typically  asked  to  accept  modifications  of  evaluated  prod- 
ucis,  and  are  often  faced  with  unevaluated  products  built  on  evaluated  platfonns.  They 
need  help  with  questions  such  as  the  following:  Was  a given  DBMS  built  on  a B 1 plat- 
form in  such  a way  as  to  destroy  its  Bl-ness?  What  is  the  impact  of  adding  Ethernet 
cards  and/or  X>windows?  Can  I&A  be  done  with  smart  cards  or  biometric  devices 
instead  of  with  passwords? 

Rom  an  accreditor's  point  of  view,  the  issue  of  composition  of  secure  products  is  a real 
concern.  TCSEC  evaluations  typically  have  not  dealt  with  this  issue.  The  Trusted 
Network  Interpretation  (TNI)  and  TDI  interpretations  take  some  initial  strides  by  articu- 
lating partitioned  and  subsetted  TCB  architectures.  However,  what  is  to  be  provided  in 
evaluation  reports  with  respect  to  allowable  *1rusted  composition"  alternatives  (e.g.,  the 
methods  for  interfacing  an  plication  on  the  product  when  one  or  both  have  been  eval- 
uated, or  when  the  evaluated  product  is  connected  to  another  with  a different  trust 
rating)  should  be  included  in  the  criteria.  Further,  if  one  is  connecting  products  together 
for  performance  reasons,  what  are  the  limitations  with  respect  to  preserving  the  TCB- 
ness  of  the  evaluated  products? 

Another  issue  that  was  discussed  was  missing  material  that  was  needed  by  the  accredi- 
tors. Fbr  example,  the  FC  contains  nc  cpozifiz  support  for  downgraders  and  other  filters. 
Accreditors  routinely  use  this  kind  of  iatnianality  and  would  greatly  appreciate  evalua- 
tion  support  for  it 

Almost  as  an  aside,  but  still  very  important,  a comment  was  made  regarding  main- 
taining a history  and  rationale  for  key  decisions  regarding  the  system  architecture  and 
design.  Such  information,  if  made  available  to  accreditors,  certifiers,  and  integratcis 
could  be  very  instructive.  It  would  als?  be  extremely  useful  for  any  product  evaluation. 

The  need  for  evaluation  assurance  requirements  was  recognized  by  everyone  present  It 
was  strongly  felt  that  evaluations  must  be  useful  to  those  who  would  make  use  of  them. 
This  general  point  came  across  much  more  forcefully  in  the  working  session  than  in  the 
various  written  comments.  It  was  felt  that  one  of  the  major  shortcomings  of  the  TCSEC 
was  that  it  faUed  to  appropriately  articulate  and  constrain  what  evaluators  do.  The 
rationale  expr^ised  for  nosding  evaluation  assurance  requirements  included:  (1) 
ensuring  thai  vcTidors  aiul  evaluators  know  *Vhat  they  are  getting  into,"(2)  ensuring 
onifonnity  of  evaluation,  *Vhat  counts  for  success,"  across  organizations  and  nations, 
and  e^)ecialiy  (3)  improving  the  utility  of  the  evaluation  output 
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OthCT  primary  points  of  this  discussion  were  the  following: 

• Evaluations  should  be  geared  to  ensuring  that  those  who  use  the  results  of  evalua- 
tions get  what  they  need  to  know. 

• Evaluation  must  be  done  in  such  a way  that  it  doesn’t  break  easily  under  product 
dq)loymenL 

Inter-Chapter  Dependencies 

The  discussion  included  global  perspectives  on  the  expression  of  requirements.  Since 
we  don’t  want  to  be  too  general  or  too  prescriptive,  the  requirement  for  expressing  what 
to  build  and  what  counts  for  success  remains  an  issue.  From  the  discussion,  we  still 
seem  to  have  bi-polar  views  endorsing  on  the  one  hand,  increased  generalization  to 
allow  vendor  flexibility,  and  on  the  othCT  hand,  increased  detailed  specifications  to 
constrain  evaluator  interpretations.  Since  the  criteria  written  to  date,  including  the  PC. 
provide  mostly  generalized  expression  of  requirements,  the  criteria  themselves  mandate 
both  vendor  and  evaluator  interpretation.  This  is  a natural  process,  but  it  has  led  to 
adversarial  relationships  and  some  ’’leligious”  conflicts  between  vendors  and  evalua- 
tors. 

It  was  noted  that  dependency  linkages  between  and  among  functional,  developmental, 
and  evaluation  requirements  should  be  explicitly  noted  at  ^propriate  points  in  conjunc- 
tion with  a requirement  statement 

One  thing  that  did  seem  important  to  the  discussicxi  was  the  need  to  express  the  func- 
tional and  development  requirements  in  measurable  (qualitative  and/or  quantitative) 
terms  and  directly  link  both  vendor  and  evaluator  actions  to  these  requirements.  This 
action  linkage  is  important  whenever  the  requirements  are  qualitative,  and  subjective 
judgement  must  be  applied. 

Additionally,  the  issue  of  proprietary  information  contained  in  evaluator  criteria  inter- 
pretations was  discussed.  Since  many,  if  not  most,  of  these  evaluator  interpretations 
involve  assessments  of  one  or  more  vendor’s  solutions  (expressed  in  proprietary  terms) 
against  a particular  TCSEC  requirement,  these  interpretations  are  not  available  to  the 
vendors  at  large.  Since  the  evaluators’  interpretations  provide  a measure  (in  some  cases 
an  extremely  significant  measure)  of  what  counts  for  success,  a means  to  publicly 
express  this  measure,  without  compromising  propHietary  information,  must  be  devised. 

Evaluation  Organizations  and  Processes 

The  discussion  also  included  the  issue  of  the  evaluation  process.  The  only  security 
produa  evaluation  organization  with  extensive  experience  is  NS  A.  The  European 
Commercially  Licensed  Evaluation  Facilities  (CI.EFs)  and  the  use  of  the  ITSEC/ 
ITSEM  (Information  Technology  Security  Evaluation  Manual)  is  only  just  beginning. 
The  NIST  TTAP  proposal  remains  on  the  “drawing  board”  in  a conceptual  form 
awaiting  additional  details,  approval,  and  resources.  Thus,  the  discussion  of  process  was 
only  discussed  at  a very  general  level.  However,  some  important  issues  did  arise. 

For  example,  since  evaluation  processes  are  not  publicly  articulated  in  detail,  the  “up 
front”  understanding  by  both  vendors  and  evaluators  of  what  is  involved  in  reaching  an 
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evaluation  rating  remains  open-ended.  It  was  acknowledged  that  the  U.S.  TPEP 
Management  Handbook  has  important  process  details  that  need  to  be  made  more  public 
in  a fashion  similar  to  the  ITSEM. 

Ibking  a different  tack,  a suggestion  was  to  examine  new  models  of  evaluations.  For 
example,  many  software  vendors  do  intonnal  evaluations  to  better  their  products.  The 
FAA  does  assurance  by  requiring  an  airplane  vendor  to  get  senior  employees  to  certify 
the  plane  according  to  FAA  standards.  Thus,  the  vendor  does  the  evaluation  at  the 
vendor’s  expense,  using  senior  staff.  The  PC  could  provide  a model  for  doing  evalua- 
tions. Standards  for  the  evaluation  process  need  not  only  apply  to  outside  evaluations. 

Still  another  tack  was  the  concq>t  of  standardized  conformance  testing  suites.  The 
subjectivity  behind  testing  requirements  could  be  greatly  reduced  by  supplementing  a 
protection  profile  with  a conformance  test  suite.  POSDC  conformance  tests  were  given 
as  an  example. 

Significant  in  the  discussion  was  the  recognition  that  process  information,  being  more 
dynamic,  should  be  published  separately  from  the  evaluation  criteria.  This  would  allow 
foi  independent  process  evolution.  The  content  of  the  Evaluation  Criteria  itself  should 
be  (com  the  point  of  view  of  business  management)  largely  ’'process-free.”  It  should  be 
results  oriented  to  achieve  ’'objective**  repeatability.  An  exception  to  this  is  subjective 
requirements  which  clearly  require  evaluation  guidance  (e.g.,  in  the  form  of  amount  of 
testing  per  1000  lines  of  c^e). 

It  was  suggested  that  to  make  the  criteria  process-free  requires  that  evaluator  activities 
be  ’’normalized**  and  linked  to  the  functional  and  developmental  requirements.  Then, 
sq)arate  evaluation  process  and  oigaiuzational  documents  for  each  type  of  evaluation 
agency  can  be  produced,  based  on  these  normalized  activities.  These  documents  would 
be  companion  documents  to  the  PC.  These  sepaatt  documents  would  contain  the  more 
dynamic  business  processes  associated  with  evaluations  (e.g.,  types  of  products  to  be 
evaluated,  length  of  an  evaluation,  specific  procedural  interactions  between  the  vendor 
and  the  evaluation  team,  use  of  a vendor  security  analyst,  how  many  resources,  qualifi- 
cation i^vels).  They  would  not  be  a ’’standard**  per  se,  but  rather  a set  of  acceptable  eval- 
uatior.  business  practices  that  in  actual  use  would  be  conditioned  by  organizational 
evolution,  organizational  goals,  budget,  available  skilled  evaluator  resources,  vendor 
readiness,  etc. 

Another  point  raised  in  the  discussions  was  rqreatability  of  results.  This  does  not  mean 
that  multiple  evaluation  agencies  must  all  be  run  in  the  same  way,  but  rather  that  the 
quality  of  the  output  remains  equivalent  across  evaluations  (i.e.,  a product  evaluated  by 
one  agency  would  get  the  same  rating  from  another  agency).  If  it  is  perceived  tha:  • 
vendor  can  get  an  ’’easier**  evaluation  from  one  or  more  evaluation  agencies,  Vrr:  :. 
’’shopping  around**  will  occur  aixl  the  entire  process  will  lose  credibility.  Thus. 
dures  for  maintaining  quality  control  across  evaluation  agencies  must  b&  devise;.. 

In  sununarizing  this  portion  of  the  discussion,  it  was  a primary  requirement  (strongly 
held  opimon)  of  the  group  that  the  PC  (or  the  ensuing  Common  Criteria)  have  such 
compamon  process  documents  produced  concurrently  with  the  actual  evaluation 
criteri;.  Having  the  evaluation  processes  articulated  and  resources  in  place  is  especially 
important  if  the  resulting  criteria  are  to  undergo  a trial  use  period  in  a timely  fashion. 
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Need  for  Additional  Material 

Evaluator  Ou^t:  As  stated  above,  requirements  are  needed  as  to  how  evaluators  report 
on  their  work.  The  ITSEM  contains  specific  requirements  that  aim  to  provide  useful 
infonnaticxi  about  inducts  in  an  Evaluation  Technical  Report  The  importance  of  such 
requirements  is  underscored  by  widespread  criticisms  of  Final  Evaluation  Reports  as 
being  neither  timely  nor  meaningful  to  potential  users  of  products.  Accreditors  need  to 
be  asked  what  they  need,  and  evaluators  need  to  receive  feedback  as  to  whether  their 
reports  are  serving  a useful  purpose. 

Qosely-Held  Source  Code:  A software  assurance  technique  that  is  in  neither  the 
TCSEC  nor  the  FC  is  to  develop  software  using  cleared  users  and  then  to  only  distribute 
the  object  code.  An  example  was  given  where  ITSEC  E3  assurance  would  be  needed  if 
source  code  was  distributed  and  ITSEC  E2  assurance  if  not 

Other  Significant,  Relevant  Issues 

A few  ideas  provided  during  the  working  session  on  protection  profiles  seem  to  be  more 
relevant  to  Chapter  6 than  to  protection  profiles  and  are  thus  presented  here  instead  in 
order  to  improve  readability  of  the  summary  reports. 

Need  for  Clarity.  Requirements  must  be  clear  and  unambiguous.  Unclear  requirements 
inspire  an  adversarial  relationship  between  vendors  and  evaluators  and  slow  down  the 
evaluation  process. 

Assurance  Objectives.  How  does  one  market  assurance?  How  does  one  arrive  at  a 
concrete  figure  as  to  the  value  of  a given  kind  of  assurance?  Other  industries  face 
similar  questions.  How  does  the  phone  company  decide  on  a level  of  protection  for  a 
cable  vault?  How  does  an  airbag  manufacturer  decide  on  the  thickness  of  airbags? 

Relevant  NCSC  Literature.  There  seem  to  be  many  relevant  documents  that  are  in 
review  or  have  just  come  out  that  are  relevant  to  evaluation  assurance.  One  document 
that  could  contribute  to  evaluation  aspects  is  **A  Guide  to  Procurement  of  Trusted 
Systems,”  Volumes  1-4,  NCSC-TG-d24,  December  1992.  Other  relevant  draft  docu- 
ments are  being  developed  on  improving  Final  Evaluation  Reports,  on  the  form  and 
content  of  vendor  test  documentation,  and  on  the  form  and  content  of  vendor  design 
documentation. 

Security  Targets  and  Protection  Profiles.  How  should  evaluators  note  that  a security 
target  or  product  is  "better”  than  a profile?  If  a particular  security  target  realizes  some 
protection  profile  but  also  provides  some  additional  features,  then  profile-vetting 
requirements  may  2pp\y  to  these  additional  features,  so  that  evaluation  teams  become 
involved  in  the  same  kinds  of  activities  as  profile  vetters. 
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CHAPTER  6 Development  Assurance 


Working  Group  Objectives 


The  Development  Assurance  Working  Group  (DAWG)  moderator  presented  the  objec- 
tives and  scope  for  the  working  groi^.  The  objectives  fen*  the  working  group  were  two- 
fold* 

• Focus  on  philosophical  and  major  technical  issues,  questions,  or  concerns  with  those 
portions  of  the  FC  that  relate  to  development  assurance  requirements. 

• For  each  issu^quesdon  discussed,  attempt  to  identify  possible  solutions  or  alterna- 
tive directions  that  address  the  issue/question. 

Several  issues  were  specifically  deemed  to  be  in  or  out  of  scope  for  the  working  group. 
Specifically  in  scope  were  all  aspects  of  technical  **assurance*’  (excluding  those  issues 
based  solely  on  evaluatkm  activities  which  was  the  topic  for  a separate  woricing  group), 
and  an  related  parts  of  the  FC  (which  was  principally  chapter  5).  SpecificaUy  out  of 
scope  for  the  DAWG  were  issues/questions  that  did  not  impact  on  the  question  of  tech- 
nical assurance,  or  were  solely  related  to  evaluation  activities;  and  technologies  not 
currently  within  the  scope  of  the  draft  FC  (e.g.,  distributed  systems,  cryptography). 


Summary  of  Written  Comments 


Prior  to  the  workshop,  the  moderators  reviewed  the  written  comments  on  the  draft  FC. 
NSA/NIST  received  111  sets  of  written  comments.  Fif^-seven  of  these  contained 
comments  specifically  related  to  development  assurance.  To  initiate  technical  discus- 
sions, the  moderator  presented  a summary  of  these  comments.  The  salient  points  from 
this  summary  presentation  are  captured  in  this  section. 


FEDERAL  CRFFERIA  WORKSHOP  PROCEEDINGS 


29 


Dev0lopment  Assurance 


The  moderator  distilled  the  written  comments  into  three  general  questions,  and  offered 
these  questions  as  starting  points  for  discussions.  The  questions  w^e: 

1.  Is  the  PC’s  assurance  paradigm  satisfactory?  If  not,  why  and  what  are  some  altema* 
tive  approaches? 

2.  Does  the  expression  of  development  assurance  requirements  as  “components”  have 
utility?  Can  assurance  be  defined  as  “components”  that  are  composed  into  profile 
requirements?  Can  technical  assurance  requirements  be  defined  genetically  in  a way 
that  would  satisfy  most  needs? 

3.  What  are  the  major  technical  problems  with  the  PC’s  development  assurance 
“components?”  Are  there  any  assurance  technologies  missing,  misrepresented,  or 
incorrectly  stated? 

For  each  of  these  questions,  summaries  or  paraphrases  of  selected  written  comments 
were  presented.  These  comments  summaries  are  listed  below.  The  items  listed  below 
are  the  moderator’s  paraphrase  and/or  summary  of  written  comments  as  presented  to  the 
DAWG.  They  are  not  exact  quotes  from  the  written  comments.  The  items  are  listed  in 
no  particular  order. 

QUESTION  1:  Is  the  PC’S  Assurance  Paradigm  Satisfactory? 

• The  PC  confuses  the  concepts  of  TCB  and  a reference  monitor,  and  often  ignores  the 
foundational  importance  of  these  concepts.  This  can  lead  to  developers  spending 
endless  effort  addressing  trivial  issues  and  ignoring  the  more  important  concerns. 

• The  argument  that  some  of  the  TCSEC’s  security  architecture  requirements  are  fimc- 
tionality,  and  not  assurance,  is  inaccurate  and  must  be  re-thought 

• Despite  repeated,  detailed  suggestions,  the  PC  still  fails  to  include  Beta-testing  as  an 
assurance  requirement  Beta-testing  is  a primary  assurance  method  for  commercial 
vendors. 

• All  of  the  assurance  requirements  apply  to  the  TCB  and  not  to  the  entire  product 
This  restriction  is  too  strong.  Some  requirements,  for  example  configuration 
management  should  irxrlude  the  entire  product 

• Operational  assurance  needs  to  be  decoupled  from  the  functionality  requirements 
arid  treated  sq}arately  from  functionality  and  development  assurance  (much  like  the 
ITSEC’s  effectiveness  requirements). 

• We  expected  the  PC  would  be  able  to  handle  conceptually  complex  systems. 

• The  PC  suggests  that  the  existence  of  a defined  TCB  is  a mandatory  requirement  for 
any  produa  to  be  evaluated.  The  ITSEC  view  is  that  while  a defined  TCB  is  a valid 
method,  it  is  not  the  only  method  for  achieving  assurance. 

• The  chief  concern  is  that  the  basis  in  science  on  which  the  TCSEC  is  based  (i.e.,  the 
reference  monitor  concept)  is  clearly  not  the  basis  upon  which  the  PC  is  founded. 
Certain  aspects  of  some  security  policies  (e.g.,  confidentiality  and  integrity)  can  be 
implemented  with  high-assurance  using  the  reference  monitor  concept  Others 
caruiot  (e.g.,  availability).  The  PC  should  embrace  the  reference  monitor  concept  for 
high-assuranoe  while  recognizing  the  utOiry  fand  limitations)  of  low-assurance 
mechanisms. 

• The  PC  lacks  a single,  consistent  assurance  paradigm,  and  in  some  respects  destroys 
the  TCSEC’s  operational  assurance  requirements. 
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• Much  of  the  FC  constrains  the  implementation  of  a TCB  in  wder  to  ensure  that  secu- 
rity is  upheld.  The  ITSEC  is  much  less  constraining,  and  instead  emphasizes 
ensuring  that  the  security  enforcing  functions  are  implemented  correctly  and  effec- 
tively. 

• There  is  no  direct  equivalent  to  the  ITSEC’s  effectiveness  criteria,  although  many 
aspects  of  effectiveness  are  covered  in  the  functionality  and  assurance  components. 
Effectiveness  should  be  treated  separately. 

QUESTION  2:  Does  the  expression  of  development  assurance 
requirements  as  **componems*’  have  utility? 

• Many  of  the  QUESTION  1 comments  apply  here. 

• The  “Construction  of  Profiles”  chapter,  which  discusses  how  component  are 
composed  together,  is  difficult  to  understand,  and  the  process  it  defines  for  compo- 
nent constructions  seems  overly  complex. 

• The  assurance  requirements  are  unnecessarily  complex. 

• The  assurance  requirements  are  easy  to  meet;  breaking  them  into  five  separate  divi- 
sions with  impressive  sounding  names  provide  very  little  actual  assurance  but  a 
major  increase  in  the  perception  of  assurance. 

• The  FC  struaure  spends  considerable  effort  emphasizing  trivial  issues  (e.g.,  the 
specification  of  numerous  security  functions)  and  spends  little  effort  on  the  issues  of 
foundational  importance  (e.g.,  the  reference  monitor  concept,  assurance). 

QUESTION  3:  What  are  the  Major  Technical  Problems  with  the  PC’s 
Development  Assurance  Comporients? 

• Concepts  are  introduced  which  are  neither  commonly  accepted  nor  adequately 
described.  These  include: 

• • Design  principles  such  as  mandated  use  of  “high-level  synchronization 

constructs,”  multi-thieaded  tasks  for  TCB  processes,  and  allowed  layering  viola- 
tions. 

• • A variety  of  modelling  concq>ts:  “penetration  models,”  “TCB  isolation  models,” 

a “model  of  reference  mediation,”  and  a “model  of  access  control.” 

• • Re-definitions  of  functional  and  penetration  testing. 

• Terminology  is  used  in  a confusing  and  historically  inconsistent  manner.  Some 
examples  are: 

• • TCB,  Reference  Monitor  concq)t,  and  Reference  Validation  Mechanism  are 

misused  and  confused. 

• • needless  new  terms  like  Descriptive  Interface  Specification  (DIS)  and  Formal 

Interface  Specification  (FIS)  are  introduced  in  place  of  the  understood  and 
accepted  Descriptive  Top-Level  Specification  ^TLS)  and  Formal  Top-Level 
Specification  (FILS). 

• • the  term  “formal”  is  overloaded  (Le.,  using  formal  to  mean  something  other  than 

mathematica]  rigor). 

• • the  principal  of  least  privilege  is  trivialized  and  mechanized. 

• • the  BeD-La  Padula  model  is  incorrectly  defined. 
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• Evidence  requirements  have  been  sq)arated«  resulting  in  two  different  statements 
(with  potentially  differing  interpretations)  for  the  same  requirement 


Summary  of  Working  Group  Discussions 


Most  of  the  working  group  deliberations  consisted  of  **open,  moderated  debate.**  At  the 
outset  the  discussions  were  directed  towards  the  three  questions  briefed  by  the  moder- 
ator, plus  any  additional  questions  the  working  group  thought  were  pertinent  and  that 
were  within  the  DAWG*s  scope.  One  additional  philosophical  question  was  added  to  the 
moderator's  list  before  debate  begun: 

QUESTION  4:  Why  does  not  the  FC  allow  profiles  to  include  the  concept  of 
^'balanced  assurance?" 

As  defined  in  the  draft  FC,  a profile's  assurance  requirements  are  monolithic,  i.e.,  they 
iQ}ply  equally  to  all  security  policy  features.  The  notion  of  balanced  assurance  would 
allow  some  security  mechanisms  (e.g.,  discretionary  access  control,  virus  detection 
techniques)  to  be  implemented  with  less  assurance  than  other  security  mechartisms  (e.g., 
label-based  protection,  certain  integrity  constraints). 

The  DAWG  did  not  have  the  opportunity  to  discuss  this  new  question.  No  one  objected 
to  this  question  when  it  was  firn  offered,  and  several  participants  noted  their  agreement 
After  further  discussion,  arx>ther  question  kq)t  arising  and  merits  recognition  as  an  addi- 
tional philosophical  concern: 

QUESTION  5:  What  are  the  assurance  objectives  of  the  draft  FC?  What 
should  they  be? 

As  described  below,  several  definitions  for  assurance  were  debated.  A (rare)  group 
consensus  was  that  the  FC  should  specifically  motivate  its  assurance  requirements  with 
definitions  and  objective  statements.  It  is  possible  for  the  FC  to  have  multiple  (different) 
assurance  objectives. 

The  working  group  started  by  discussing  the  questions  raised  by  the  moderator,  but  the 
group  dynamics  quickly  led  to  other  related  topics. 

The  remainder  of  this  section  captures  the  key  points  raised  during  the  DAWG's  discus- 
sion. 

Definitions  of  Assurance 

At  the  repeated  prompting  of  one  participant,  the  working  group  listed  possible  mean- 
ings for  "assurance."  This  discussion  is  probably  best  characterized  as  an  exercL^'  in 
answering  the  question  "What  does  assurance  mean  to  me?"  The  following  bnc:  defini- 
tions were  put  forth. 

• Techrtiques  that  provide  "confidence"  in  the  implementation  of  security  mechanisms 
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• Risk/threat  mitigation  techniques  (i.e.,  threats  are  impcniant  in  the  definition  of 
assurance) 

• Assurance  = verification  and  correctness  with  respect  to  some  specified  objective 

• Techniques  that  increase  one’s  ability  to  analyze  and  understand  the  security  mecha- 
nisms. 

• Trustworthiness  (as  opposed  to  Tnistedness — a reference  for  these  terms  was  given 
to  the  jtaptT  by  Peter  Neumann  titled  “On  the  Design  of  Dependable  Computer 
Systems  for  Critical  ApplicatitMis,  SRI-CSL-9()-10,  SRI  IntOTiational,  October 
1990). 

• Effectiveness,  as  defined  in  the  European  Information  technology  Security  Evalua- 
tion Criteria  (TTSEQ 

• Reliability 

• Vendor  warranties  and  guarantees 

In  an  attempt  to  Ining  the  discussion  back  to  the  FC,  the  DAWG  addressed  the  question 
of  what  did  the  FC  mean  by  “assurance.”  To  provide  a basis  for  comparison,  the  group 
first  addressed  the  question  of  what  assurance  meant  to  the  TCSEC,  the  ITSEC,  and  the 
CTCPEC,  all  of  which  were  sited  as  key  source  documents  for  the  FC.  Fortunately, 
there  were  individuals  participating  in  the  DAWG  that  were  principal  participants  in  the 
development  of  each  of  these  standards  and  were  able  to  offer  their  view  of  this  ques- 
tion. 

TCSEC:  Evideix:e  that  a particular  security  policy  is  correctly  implemented  using  the 
reference  monitor  concept 

ITSEC:  Effectiveness,  correctness,  and  ease-of-use. 

CTCPEC:  Exactly  the  same  as  the  TCSEC  but  for  a potentially  larger  set  of  policies, 
ix.,  evidence  that  some  specified  security  policy  is  correctly  implemented  using  the 
reference  monitor  concept  The  CTCPEC  also  meant  to  “open  the  door”  for  vendor  self- 
assuraixx. 


Draft  FC:  Correctness  and  understandability,  and  maintenance  of  these  traits  over  time 
(effectiveness  was  specifically  excluded  from  this  definition  and  is  intended  to  be 
addressed  by  the  protection  profile  development  and  acceptance  C'vetting*’)  process). 

Process  versus  Product  Assurances 

The  DAWG  had  a long  discussion  on  types  of  assurances;  specifically  “product  assur- 
ance” and  “process  assurance.”  Roughly  speaking  product  assurance  is  gained  through 
the  design,  implementation,  and  analysis  of  a product,  and  process  assurance  is  gained 
through  the  controls  and  procedures  used  to  ensure  the  quality,  safety,  and  security  of 
the  development  process  and  development  environment 

Though  the  DAWG  discussed  this  topic  at  some  length,  no  general  consensus  was 
reached.  The  way  in  which  this  view  of  assurance  is  addressed  by  the  FC  was  also  not 
significantly  discussed.  Some  felt  the  FC  (and  other  security  standards)  focused  too 
much  on  produa  assurances.  Others  felt  the  FC  focused  too  much  on  process  assurance. 
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and  that  these  were  of  lesser  importance.  Others  sdll  thought  both  were  important,  but 
had  to  be  balanced  with  the  expected  threats  and  expected  level  of  assurance. 

QUESTION  2:  Does  the  expression  of  development  assurance 
requirements  as  **components*’  have  utility? 

The  DAWG  discussed  this  question  at  length.  The  general  consensus  was  that  compo- 
nents give  the  profile  developer  flexibility,  but  they  also  carry  some  significant  liabili- 
ties. Much  of  the  debate  centered  around  these  liabilities,  and  whether  they  justified  the 
flexibility  gained. 

Uabllitias  Associated  with  Components 

The  liabilities  discussed  fell  into  two  major  areas: 

•,  Complexity 

• Problems  with  Reconstruction 

Complexity:  There  was  a consensus  that  the  FC*s  current  concept  of  requirement 
components  and  profile  construction  was  too  complex  and  may  be  impractical  as 
defined.  One  person  noted  that  the  CTCFEC  at  one  time  had  a component  concq)t  for 
assurance  requirements,  but  removed  it  in  feivor  of  complete  sets  of  assurance  require- 
ments  due  to  its  complexity.  It  was  noted,  however,  that  the  CTCPEC’s  components 
were  targeted  at  vendors,  evaluators,  and  system  pnx;urers  whereas  the  FC*s  compo- 
nents are  targeted  at  profile  writers  and  approvers  (with  the  presumption  that  this  latter 
audience  was  smaller  and  more  sophisticated).  Most  felt  that  the  PC’s  current  concept 
must  be  simpler  to  be  successful.  Tbere  was  a great  deal  of  concern  about  the  possibility 
of  technically  inaccurate,  invalid,  or  inappropriate  profiles  being  developed.  This  last 
point  led  to  Ae  next  liability:  problems  with  reconsouction. 

Recoostmction:  The  problems  with  leconstniction  of  coherent  whole  sets  of  require- 
ments from  requirement  components  was  discussed  at  length  by  the  DAWG.  The  prin- 
dple  concern,  which  was  labdled  **bundled  versus  bungled**  by  one  participant,  is 
whether  the  breaking  of  coherent  whole  sets  of  assurance  requirements  into  very  small 
components  and  then  reconstructing  the  whole  requirement  again  introduces  opportuni- 
ties for  technically  flawed  (and  potentially  harmful)  protection  profiles.  Most  of  this 
discussion  centered  around  the  profile  development  and  accq}tance  C*vetting**)  process, 
since  the  problems  with  reconstruction  places  a strong  emph^is  the  profile  ^'vetting** 
process. 

Several  participants  noted  that  it  will  be  difficult  to  maintain  a ^‘corporate  memory** 
during  the  years  in  which  the  PC  would  be  in  effect  The  prime  example  of  this  problem 
was  an  analogy  of  the  TCSEC  and  its  writers.  For  over  a decade  the  vendor  and  evalu- 
ator communities  have  debated  and  interpreted  the  meanings  of  the  TCSEC  require- 
ments (the  general  consensus  was  that  the  TCSEC  is  a simpler  problem  than  the  FC 
since  the  TCSEC  is  itself  simpler  and  more  narrowly  focused).  Even  though  it  was  first 
published  only  ten  years  ago,  arxl  all  of  the  authors  are  alive  and  active  within  the 
community,  the  rationale  for  the  way  in  which  the  TCSEC  requirements  were 
consoiicted  are  not  captured  in  any  single  place.  Many  experienced  engineers  misinter- 
pret its  meanings  and  attempt  to  combine  requirements  in  less  than  meaningful  ways 
(examples  of  this  latter  case  included  rigorous  design  specifications  for  B 1-like  assur- 
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ance,  fonnal  verification  without  formal  policy  models).  No  one  believes  what  the 
TCSEC  authors  now  say  was  their  intent  (this  is  the  problem  of  the  “authors  being 
dead**  once  standards  are  published).  Many  working  group  memb^  suspected  that  the 
same  problems  will  occur  with  the  FC,  but  will  be  amplified  due  to  the  codification  of 
requirement  components  and  the  s^Tparent  encouragement  of  the  development  of  many 
profiles. 

Another  concern  with  reconstruction  focused  on  the  possibility  of  combining  two  sets  of 
requirements,  and  losing  the  meaning  of  one  or  both  of  them.  One  example  discussed 
was  combining  informaticm  flow  controls  covert  channel  handling)  with  some  fault 
tolerance  techniques.  Fault  tolerance  often  requites  a lot  of  data  to  flow  via  many 
different  paths  whereas  information  flow  control  tries  to  restrict  the  flow  of  data  to  a few 
well-defined  paths.  It  is  unclear  whether  we  understand  what  a combined  fault-tolerant/ 
information  flow  control  criteria  would  be,  yet  if  both  types  of  components  existed  (and 
each  were  technically  sound  as  separate  components),  it  is  likely  that  a profile  will  be 
constructed  the  combines  both  of  these  requirements.  The  group  felt  that  many  other 
such  examples  exist,  and  were  unsure  that  the  “vetting*'  process  could  control  these 
potentially  harmful  combinations. 

The  last  conc^  with  reconstruction  was  with  the  evolution  of  de  facto  standards.  The 
issue  is  that,  even  assuming  that  the  “vetting**  process  can  control  the  quality  of  profiles, 
it  is  likely  that  vendOTS  or  some  third-party  organization  will  develop  profiles  that  are 
not  “vetted**  and  that  these  profiles  will  become  de  facto  standards.  Much  of  the  discus- 
sion on  this  issue  focused  on  the  current  NS  A Trusted  Product  Evaluation  Process 
(TPEP),  and  the  ways  in  which  some  B1  and  Bl-like  Compartmented  Mode  W^ksta- 
tion  (CMW)  vendors  imply  that  their  products  are  B2,  B3,  or  even  Al-like  since  they 
were  “designed  to  meet**  certain  higher-level  requirements  (which  are  never  the  really 
important  and  most-difficult-to-satisfy  higher-level  requirements).  Many  DAWG 
members  felt  that  this  problem  will  be  even  greater  with  the  FC  since  requirement 
components  are  officially  recognized  and  separately  labelled.  Vendcxs  who,  for 
example,  may  want  to  imply  that  their  product  is  almost  LP-2  or  higher,  can  pick  certain 
components  that  were  part  of  LP-2  (but  not  the  most  important  and  most  difficult  ones), 
and  claim  that  they  meet  them.  Some  felt  that  this  was  a significant  flaw  with  the  notion 
that  the  profile  “vetting”  process  can  control  the  quality  of  profiles.  [FOOTNOTE:  One 
person  half-seriously  suggested  that  the  labels  for  ccxnponents  and  profiles  should  be 
copyright  protected  as  was  done  with  Ada  to  prevent  “unvetted”  combination  of 
requirements.  Most  felt  this  could  not  hurt — if  practical — but  would  not  address  all  the 
concerns.] 

Liabilities  versus  Benefits 

After  discussing  the  potential  liabilities  with  requirements  components,  the  working 
group  discussed  whether  the  benefits  of  components  out-weighed  their  liabilities.  Most 
of  the  DAWG  were  reluctant  to  drop  the  notion  of  components  from  the  FC  and  thought 
that,  at  least  in  theory,  it  was  a good  idea.  However,  there  was  also  a great  deal  of 
concern  whether  components  and  subsequent  reconstruction  into  profiles  was  practical. 
Some  DAWG  membos  felt  we  do  not  have  sufficient  understanding  of  requirement 
components  (the  understanding  we  lack  has  been  called  the  “algebra  of  components”), 
and  the  FC  should  not  depend  on  what  is  essentially  a research  issue  (Le.,  the  FC  should 
address  whole  protection  profiles  or  large  sets  of  requirements  like  assurance  ^'pack- 
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ages**  rather  than  requirement  components).  One  person  gave  the  analogy  that  “two 
arms,  two  legs,  a torso,  and  a head  does  not  necessarily  make  a person.** 

This  discussion  led  to  the  issue  of  quality  control  over  components.  Repeatedly,  the 
group  heard  that  the  “vetting**  process  will  control  the  quality  of  profiles,  but  there 
seemed  to  be  no  similar  control  over  components.  When  a participant  asked  how  new 
components  are  included,  the  answer  was  that  they  are  introduced  via  “vetted**  profiles. 
The  discussion  then  focused  on  whether  any  component  should  be  included  in  the  FC 
unless  it  has  first  been  “vetted**  in  a profile,  and  then  the  requirement  should  be  taken  as 
a whole  from  the  profile.  The  group  observed  that  more  than  two*thirds  of  the  compo* 
nents  listed  in  the  FC  were  not  included  in  the  FC*s  example  profiles.  Some  felt  that 
“unvetted**  components  should  be  strictly  harmed,  since  there  will  be  the  impression  that 
if  a component  is  listed  in  the  PC,  it  must  be  technically  sound.  Others  felt  that  the  out> 
right  ban  of  “unvetted**  components  may  be  too  strong,  but  that  there  should  be  some 
control  over  their  quality. 

QUESTION  3:  What  are  the  Major  Technical  Problems  with  the  PC’s 
Development  Assurance  Components? 

The  DAWG  btiefiy  discussed  the  third  question  raised  by  the  moderator.  A couple  of 
participants  asked  whether  these  were  “nits**  that  were  not  important  enough  to  discuss 
at  this  time.  However,  most  of  the  DAWG  felt  that  these  comments  were  indeed  funda- 
mental technical  issues  that  should  be  addressed  before  the  Common  Criteria  effort 
begins.  Indeed,  some  felt  the  issues  raised  in  the  written  comments  and  summarized  by 
the  moderator  (see  the  QUESTION  3 summary  in  Section  4)  are  fundamental  concerns 
that  must  be  address  prior  to  the  Common  Criteria  effort  There  was  a general  sense  that 
the  FC  was  introducing  concepts  that  are  not  well-accepted,  and  sometimes  introduced 
these  concepts  under  names  which  had  different  meanings  in  the  TCSEC,  ITSEC,  or 
CTCPEC 

Miscellaneous  Topics 

In  this  section,  various  related  tc^ics  that  were  discussed  by  the  DAWG  are  listed.  These 
topics  are  listed  in  no  particular  order. 

Some  felt  that  the  concept  of  effectiveness  as  defined  in  the  ITSEC  was  inadequately 
addressed  by  the  draft  FC.  This  concern  was  sdll  present  even  after  it  was  explained  that 
the  FC  intended  to  address  effectiveness  via  the  profile  “vetting**  process. 

Many  DAWG  participants  voiced  strong  concern  about  the  manner  in  which  the  FC 
distributed  the  TCSEC  and  CTCPEC*s  notion  of  operational  assurance,  especially  the 
system  architecture  requirements,  throughout  the  development  assurance  and  function- 
ality components.  This  structure  resulted  in  reduced  or  even  harmful  redefinitions  of  the 
system  architecture  requirements.  The  principle  example  of  this  problem  was  the  way  in 
which  the  FC  defined  Ae  least  privilege  requirements  as  solely  a set  of  mechanisms 
(some  felt  that  these  mechanisms  themselves  encouraged  poor  least  privilege  designs) 
rather  than  defining  least  privilege  as  a global  design  concern,  which  may  partially  be 
satisfied  in  some  cases  by  the  mechanisms  listed. 
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Some  DAWG  participants  felt  that  evaluation  requirements  should  be  listed  with  the 
functional  or  development  assurance  requirements. 

There  was  a general  consensus  that  “reliability”  does  not  necessarily  imply  “assurance” 
in  a security  sense.  The  example  given  was  the  phone  system,  which  is  exceptionally 
reliable  (i.e.,  phones  calls  go  through  at  rates  of  success)  but  has  been  widely  and  deeply 
penetrated  over  the  years. 

The  DAWG  generally  agreed  that  the  FC  poorly  uses  the  terms  “misted  subject”  and 
“privileged  subject”.  In  particular,  the  FC  uses  the  term  “privileged  subject”  where 
“trusted  subject”  should  be  used.  A subjea  need  not  have  privileges  in  order  to  be  part 
of  the  TCB  (e.g.,  an  unprivileged  audit  collection  utility).  Likewise,  possession  of  a 
privilege  need  not  mean  that  a subject  is  part  of  the  TCB  (e.g.,  a privilege  to  increase  or 
decrease  a process’  priority  may  be  allocated  to  non-TCB  subjects).  Oth^  noted  that 
the  FC  should  not  discuss  “trusted  subjects”  at  all,  since  it  is  an  implementation  detail. 
In  most  cases,  it  should  suffice  to  simply  distinguish  between  TCB  and  non-TCB  (and 
possibly  Reference  Monitor  and  the  non-RM  TCB). 


Summary  and  Conclusions 


The  DAWG  did  not  achieve  consensus  (Hi  a lot  of  the  issues  discussed.  This  was  due  in 
part  to  the  small  amount  of  time  available  for  discussion.  Nonetheless,  many  excellent 
points  were  raised,  the  most  significant  of  which  are  hopefully  ccHitained  in  the  material 
presented  above.  In  the  mcxlerator’s  opinion,  th^  was  general  agreement  on  a number 
of  important  issues: 

• Few  were  ha{^y  with  the  current  contents  of  Chapter  5.  There  was  not  a consensus 
on  what  Chapter  5 should  l(X)k  like,  but  many  opinicHis  w^  given  (as  discussed 
above). 

• Most  participants  liked  the  idea  of  components  in  principle.  However,  nearly 
everyone  had  serious  concerns  about  the  concept  in  i^ctice,  and  in  particular,  about 
the  FC’s  components  as  currently  defined.  The  principle  concerns  focused  on  the 
possibility  of  reconstructing  meaningless  (and  possibly  harmful)  assurance  require- 
ments from  ccHuponents,  the  lack  of  control  over  the  quality  of  individual  compo- 
nents, and  the  loss  of  meaning  by  breaking  assurance  requirements  into  components 
and  then  reconstructing  new  assurance  requirements.  This  issue  consumed  most  of 
the  DAWG’s  lime. 

• Nearly  all  participants  had  serious  concerns  about  some  of  the  technical  assurance 
concepts  introduced  in  the  FC.  Many  felt  that  some  of  the  concepts  were  not  well- 
accepted,  and  that  some  of  the  “new”  concepts  were  not  well  described  Others  were 
concerned  that  some  well-accepted  concepts  were  replaced  by  less-accepted  or 
poorly  described  “new”  concepts.  The  group  consensus  was  that  the  FC  should  stick 
to  accepted  concerts  and  ideas  (but  not  close  the  dcx)r  on  new  ideas  being  introduced 
in  the  future). 
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CHAPTER  7 


This  report  represents  a summary  of  the  discussion  held  during  the  Protection  Profile 
session.  Most  of  the  discussion  points  scheduled  for  this  topic  were  included  in  the 
"global  issues”  sessions  held  during  the  first  day  of  the  woilcshop.  Consequently,  a new 
set  of  questions  were  posed  by  the  moderators  for  consideration  by  the  participants.  This 
set  is  presented  below. 


Questions  Posed  by  Moderators 


The  following  questions  were  posed  by  the  moderators.  These  questions  are  listed  in  the 

order  in  which  they  were  addressed  by  the  participants. 

1.  Is  the  notion  of  a Protection  Profile  useful?  If  Yes,  to  whom  (e.g.,  users,  certifiers, 
accreditors,  evaluators)?  If  No,  why  not? 

2.  What  is  (should  be)  the  relationship  between  Protection  Profiles  and  Security 
Targets? 

3.  How  should  a Protection  Profile  be  synthesized?  Should  a formalism  be  developed 
(e.g.,  an  "algebra”  of  component  synthesis  be  developed)?  Or  should  a series  of 
informal  steps  illustrating  the  use  of  criteria  components  be  provided? 

4.  Should  the  description  of  the  process  of  developing,  vetting,  registering,  changing  a 
Protection  Profile  be  included  in  the  Federal  Criteria,  or  should  a separate  document 
O-e.,  guideline)  be  developed? 
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Participants 


1.  In  addressing  the  first  question,  most  of  the  participants  had  already  agreed  (in  a 
prior  session)  that  the  notion  of  a Protection  Profile  is  useful  and  sound.  Of  some 
interest  was  tl^  fact  that,  unlike  TCSEC  classes  and  other  types  of  bundled  require- 
ments, the  Protection  Profiles  must  include  the  type  of  threats  countered,  vulnerabil- 
ities eliminated,  standards  supported,  and  regulations  addressed.  These  items, 
without  which  a protection  profile  cannot  be  vetted,  were  considered  of  particular 
interest  to  accreditors  and  certifiers,  if  not  to  evaluators.  (The  moderator  underlined 
the  fact  that  it  is  precisely  this  set  of  items  that  is  necessary  to  establish  whether  a 
profile  is  security  effective;  i.e.,  i^ether  its  functional  requirements  counter  a speci- 
fied set  of  threats,  eliminated  a specified  set  of  vulnerabilities,  supports  a specified 
set  of  standards,  addresses  a specified  set  of  regulations.) 

Much  of  the  discussion  focussed  on  the  process  of  changing  a protection  profile  (e.g., 
when,  by  whom?).  It  was  suggested  that  **minor**  deviations  from  the  anticipated  use  of 
a profile  should  be  allowed  during  profile  use  because,  in  practice,  the  environment  of 
profile  use  is  likely  to  differ,  to  some  extent,  from  that  assumed  by  the  profile  develops; 
The  notion  of  how  extensive  a change  can  be  (i.e.,  what  is  meant  by  a ^'minor**  change 
of  environment  assumption)  was  answered,  somewhat  facetioush  . by  noting  that  a 
major  change  would  always  require  a significant  expenditure  of  resources  whereas  a 
minor  change  would  only  require  a small  amount  of  resources. 

It  was  also  suggested  that  minor  changes  in  the  Protection  Profile  definition  and  use 
should  be  at  the  accreditors*  latitude.  However,  if  it  is  discovered  that  a lot  of  common 
changes  occur  in  practice,  these  common  changes  should  trigger  a profile  change,  which 
would  be  vetted  under  the  normal  procedures  (to  be  defined).  It  was  also  suggested  that 
changes  to  a protection  profile  should  also  be  made  when  security  technology  changes 
Gx.,  a technology  insertion  program  should  be  established  akin  to  some  of  the  programs 
established  by  NASA). 

A final  set  of  remarics  by  the  participants  addressed  the  need  for. 

• involving  accreditors  in  the  process  of  vetting  a Protection  Profile; 

• educating  end-users,  accreditors,  and  certifiers  in  assessing  and  using  Protection 
Profiles  in  specific  environments; 

• resisting  the  pressures  from  the  user  community  to  introduce  extraneous  details  in 
the  definition  of  a profile. 

2.  In  addressing  the  second  question,  the  participants  noted  that  neither  the  notion  of 
the  **security  target"  nor  the  relationship  between  a "security  target"  and  a Protection 
Profile  is  defined  in  the  Federal  CMteria.  However,  it  was  also  noted  that  the  product 
evaluation  process  always  involves  both  Protection  Profiles  and  Security  Targets.  It 
was  agreed  that,  for  the  purposes  of  the  discussion,  the  notion  of  the  Security  Target 
was  that  of  the  ITSEC. 

In  addressing  this  question,  the  participants  made  the  following  three  observations: 

• the  relationship  between  a Security  Target  and  a Protection  Profile  is  "many-to-one." 
That  is,  a Security  Target  may  satisfy  several  Protection  Profiles.  The  typical 
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example  would  be  that  of  a Security  Target  which  satisfies  a CMW  Profile  and,  at  the 
same  time,  satisfies  a B1  Protection  Profile.  Other  examples  of  the  “many-to-one” 
relationship  involving  widely  independent  Protecticm  Profiles  are  anticipated. 

• the  relationship  between  a Security  Target  and  a Protection  profile  may  be  affected 
by  the  product  configurations.  For  example,  two  configurations  of  the  same  product 
may  satisfy  two  different  Security  Targets.  Also,  it  was  noted  that,  although  a certain 
product  configuration  change  may  satisfy  some  Security  Target  that  differs  from  the 
intended  one,  the  configuration  may  disable  desirable  features,  which  would  cause 
the  product  not  to  satisfy  any  Protection  Profile.  These  configurations  were  called 
the  ^^conflicting  configurations,**  and  were  distinguished  from  those  that  could  lead 
to  secure,  but  **less-than-useful**  products. 

• the  role  of  the  Protection  Profiles  and  Security  Targets  in  the  certification  and 
accreditation  process  should  be  defined  in  the  Federal  Criteria  (or  other  ancillary 
documents). 

3.  The  third  questicxi  was  addressed  by  several  participants,  each  providing  different 
views  on  what  was  important  in  synthesizing  Protection  Profiles.  A common  point  of 
agreement  was  that,  although  formalisms  for  composing  requirement  components 
are  generally  desirable,  it  is  premature  to  consider  such  formalisms  given  the  fact 
that  the  requirement  components  themselves  are  informally  defined.  The  following 
three  observations  were  also  generally  accepted  by  the  participants: 

• the  steps  provided  by  the  Federal  Criteria,  Chapter  7,  seem  to  form  an  adequate  basis 
for  profile  synthesis.  However,  the  synthesis  process  is  not  documented  for  the 
Protection  Profiles  examples  included  in  Volume  n.  Without  such  documentation  it 
is  somewhat  difficult  to  determine  with  cotainty  whether  the  steps  provided  in 
Chapter  7 are  sufficient  for  profile  synthesis  in  practice. 

• the  profile  synthesis  should  include  some  “mandated**  components  for  both  func- 
tional and  assurance  requirements.  It  was  noted  by  the  moderators  that  the  Federal 
Criteria  already  mandates  three  functional  components;  Logical  TCB  Protection, 
Reference  Mediation,  and  Security  Policy.  The  participants  suggested  that  a similar 
mandated  inclusion  should  be  made  for  assurance  components,  and  the  component 
suggested  for  initial  inclusion  was  Penetration  Analysis.  During  this  discussion,  it 
was  also  noted  that  a distinction  must  be  made  between  the  penetration  analysis 
carried  out  at  product  development  and  evaluation  and  the  penetration  analysis 
performed  during  product  accreditation  in  the  environment  of  use.  Both  types  of 
penetration  analyses  were  strongly  recommended  with  emphasis  on  analysis  during 
accreditation. 

• the  introduction  of  new  components  in  the  Federal  Criteria  may  affect  existing 
profiles  not  only  future  ones.  The  questions  of  when,  why,  who,  and  how  these  new 
components  are  introduced  should  be  addressed. 

4.  The  fourth  question  was  only  tangentially  addressed  as  part  of  the  overall  discussion 
on  the  synthesis  of  Protection  Profiles.  The  sense  of  the  moderators  is  that,  given  the 
level  of  detail  required  in  illustrating  the  synthesis  of  a Protection  Profile,  the  general 
recommendation  would  be  to  provide  a (set  oO  guidelines  on  Protection  Profile 
development,  vetting,  changing,  etc. 
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Overview 


The  Commercial  Security  Requirements  (CSRs)  Technical  Working  Session  included 
presentations  from  Michael  Ressler  from  Bellcore.  Kenneth  Cutler  frxxn  MIS  Training 
Institute,  and  Ellen  O’Conner  from  the  Internal  Revenue  Service.  Both  Mr.  Ressler  and 
Mr.  Cutler  participated  in  the  NIST/NS  A working  group  that  developed  the  Minimum 
Security  Functioriality  Requirements  (MSFR).  firom  which  the  Commercial  Security 
Protection  Profiles  (PPs)  were  derived.  As  a person  responsible  for  ensuring  that 
extremely  sensitive  but  unclassified  information  is  adequately  protected  while  it  is 
managed  by  an  information  system,  Ms.  O’Conner  is  representative  of  a potential 
typical  user  of  the  CSRs  Protection  Profiles. 

In  addition  to  the  presentations,  the  session  also  provided  an  opportunity  for  participants 
to  discuss  issues  related  to  CSRs  with  the  intention  being  that  these  comments  would 
provide  input  into  the  Common  Criteria  efforts.  Participants  were  requested  to  focus  on 
general  corrunents  (rather  than  detailed  line-by-line  comments)  and  also  to  focus  on 
areas  that  were  fdt  to  represent  ’"successes”. 

During  the  discussion  portion  of  the  session,  two  major  themes  developed.  The  first 
theme  centered  around  concerns  with  certain  information  included  in  the  CSRs,  while 
the  second  theme  related  to  requirements  that  participants  felt  should  be  included  in  one 
or  more  of  the  CSRs. 

The  remainder  of  this  report  describes  the  major  concerns  discussed  by  participants  and 
their  suggestions  for  additional  requirements,  and  also  summarizes  the  presentations 
presented  the  three  invited  spedcers. 
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Concerns 


Participants  expressed  four  main  concerns  with  the  CSRs: 

1.  There  was  concern  that  the  specification  of  some  of  the  requirements  was  too 
specific.  Participants  cautioned  that  the  CSRs  should  focus  on  ^'what"  security 
feature  is  required,  not  **how**  the  security  feature  is  implemented.  They  also  pointed 
out  that  focusing  on  the  **how**  rather  than  the  ^^what"  severely  limits  irmovation. 

2.  There  was  general  concern  with  the  use  of  TCSEC  terminology  within  the  CSRs. 
The  Department  of  Defense  and  the  commercial/civil  sector  use  different  termi- 
nology. Participants  felt  that  the  use  of  TCSEC  terminology  to  describe  requirements 
causes  the  corrunercial/civil  sector  to  assume  that  the  related  requirements  are  not 
iqrplicable  for  their  environment  The  following  two  examples  were  given: 

- Cotnmercial/civilian  users  have  a need  for  mandatory  access  controls.  However, 
when  the  term  *‘laber  is  used,  there  is  a DoD  cormotation,  and  the  implicanon  is 
that  requirements  related  to  labels  are  not  relevant  to  the  commercial/civil  sec- 
tor. 

- Conunercial  users  state  that  they  do  not  require  **tnisted  distribution"  (TCSEC 
terminology),  which  connotes  couriers  and  armored  cars.  However,  commercial 
users  are  very  concerned  with  the  introduction  of  viruses  and  may  require  soft- 
ware to  be  shrink-wrtqjped.  Shrink-wrap  is  a form  of  **trusted  distribution." 

The  consensus  among  the  participants  was  that  the  CSR  profiles  must  be  cortuner- 
cialized.  Terms  that  are  not  used  in  the  commercial/civil  sectors  must  be  removed 
and  replaced  with  the  appropriate  terms. 

3.  There  was  concern  that  there  may  be  a proliferation  of  Protection  Profiles.  This  was 
expressed  by  the  question  asked  several  times  of  **How  many  PPs  will  there  be?"  It 
was  also  pointed  out  that  vendors  only  want  to  build  to  one  (or  maybe  2)  set(s)  of 
requirements. 

Consequently,  there  should  be  only  a very  limited  number  of  profiles.  It  was  suggest- 
ed that  a profile  can  support  options  so  that  different  sets  of  requirements  can  be  sat- 
isfied. 

4.  There  was  concern  that  **commercial"  was  not  a descriptive  name  for  the  CSRs  since 
there  are  other  environments  for  which  these  profiles  are  usefirl. 


Suggestions 


The  consensus  of  the  session  attendees  appeared  to  be  that  while  the  CSR  profiles  do  not 
yet  adequately  address  the  needs  of  commercial  and  government  users,  they  are  a good 
first  qrproxitnation  (with  the  possible  excq)tion  of  CSl,  which  does  not  reflect  the 
needs  of  the  users  and  should  not  be  used). 

There  were  several  recommendations  for  features  that  participar^  felt  needed  to  be 
included  in  the  CSRs.  There  seemed  to  be  consensus  that  the  major  missing  features 
related  to  networking  and  distributed  systems,  low-assurance  PCs,  and  encryption. 
Other  features  were  also  mentioned.  The  discussion  related  to  each  of  these  features  is 
described  below. 
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Networks  and  Distributed  Systems:  Participants  mentioned  that  excluding  network 
connections  resulted  in  an  “unrealistic  environment”  since  most  environments  have 
networi:  connections.  Consequently,  networks  and  distributed  systems  should  be 
addressed  by  the  Federal  Criteria.  In  a related  comment,  it  was  pointed  out  that  other 
requirements  should  take  the  networking  environment  into  consideration.  For  example, 
in  developing  authentication  (e.g.,  passwords)  requirements,  there  should  be  a recogni- 
tion of  the  fact  that  users  log  onto  multiple  systems  via  networks. 

Low-Assurance  PC  Requirements:  Attendees  stressed  that  profiles  with  lower  assur- 
ance and  functionality  are  needed  and  that  the  CS  profiles  must  address  other  environ- 
ments beyond  multi-user  operating  systems.  Profiles  that  provide  for  lower  functionality 
and  assurance  would  be  very  useful  for  both  commercial  and  government  users.  A low 
functionality/basic  assurance  profile  for  PC’s  or  workstations  may  be  q^propriate  for 
some  users. 

Encryption:  Another  missing  feature  that  was  widely  commented  on  was  the  lack  of 
requirements  related  to  encryption.  However,  someone  mentioned  that  encryption 
cannot  be  mandated  in  a Protection  Profile  because  of  export  restrictions.  Someone  else 
countered  that  although  encryption  algorithms  are  not  exportable,  the  interfaces  to  the 
algorithms  are  exportable.  There  was  some  additional  discussion  as  to  whether  this 
comment  was  correct 

Labels:  The  issue  of  the  need  for  labels  in  the  commercial  environment  generated  a 
great  deal  of  discussion  with  first  one  participant  stating  that  they  were  definitely 
required,  and  another  responding  that  they  were  not  needed.  It  was  also  noted  that 
mandatory  access  controls  are  needed,  but  that  the  term  “label”  (with  its  DOD  connota- 
tion) is  the  problem.  A suggestion  was  that  the  term  “security  tag”  be  used  rather  then 
the  term  “1^1”.  Other  attendees  pointed  out  that  labels  can  be  used  to  protect  against 
viruses  and  may  be  useful  in  protecting  against  corporate  espionage.  The  consensus 
among  attendees  seemed  to  be  that  there  is  a need  within  the  CSRs  to  include  require- 
ments related  to  mandatory  access  controls. 

Role-Based  Access  Controls  (RBAC):  The  concept  of  RBACs  was  another  topic  that 
generated  a great  deal  of  discussion.  Several  attendees  felt  that  RBACs  were  needed  in 
the  commercial/civil  section,  and  consequently,  that  requirements  related  to  RBACs 
should  be  included  in  the  CSRs.  However,  there  were  cautionary  comments  that  “roles” 
are  a new  concept  and  not  yet  well-understood,  and  that  perhaps  for  this  reason  they 
should  not  be  included  as  requirements.  In  spite  of  these  cautionary  comments,  the 
consensus  of  the  group  seemed  to  be  that,  because  RBACs  are  needed  they  should  be 
studied  for  possible  inclusion  as  requirements  in  one  or  more  of  the  CSRs.  There  were 
also  suggestions  that  the  Federal  Criteria  include  the  “primitives”  from  which  RBAC 
requirements  could  be  built. 

MSFR:  The  attendees  felt  that  “the  MSFR  was  a more  useful  protection  profile.”  The 
participants  preferred  the  approaches  used  in  the  MSFR  to  those  in  the  CS  profiles. 
Terminology,  level  of  granularity  and  clarity  of  requirements  were  all  mentioned  as 
superior  in  the  MSFR. 

The  consensus  of  the  participants  was  that  the  MSFR  work  should  be  preserved  and 
included  in  the  Feder^  Crit^  as  a Protection  Profile. 
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Ratings  Maintenance  Phase  (RAMP)  and  Official  TCSEC  Interpretations: 
Someone  commented  that  the  CSRs  appear  to  include  neither  RAMP  nor  the  interpreta- 
tions. Another  attendee  stated  that  commercial  users  do  not  care  about  RAlvQ>  Another 
attendee  stated  that  some  RAMP  requirements,  such  as  configuration  management  and 
trusted  dis&ibution,  are  needed  by  the  conunercial/civil  sector. 

Application  Programming  Interfaces  (APIs):  CSR*s  need  to  include  requirements  for 
APIs  that  can  be  used  by  application  programs  to  access  securiQ'-relevant  information. 

Malicious  Users:  The  CSRs  should  include  requirements  that  protea  against  malicious 
users. 

User  Education:  There  was  some  discussion  as  to  whether  the  CSRs  should  include 
requirements  related  to  user  security  awareness  education  since  this  acts  as  a threat 
reducer.  However,  the  consensus  of  the  participants  seemed  to  be  that  it  should  be  not 
included  as  a requirement  in  any  of  the  CSRs. 

Presentation  One  - Michael  Ressler  - Beiicore 


Mn  Ressler  presented  an  overview  of  Beiicore  and  its  securiQr  requhements.  He  stated 
that  BeUcore  security  requirements  do  not  align  with  the  TCSEC  because  the  *C'  level 
does  not  provide  enough  security  fimctionaUty  nor  assurance  and  the  hierarchical  access 
conuol  model  of  the  *B*  level  is  inappropriate  for  their  environment 

He  also  provided  an  overview  of  general  commercial  security  requirements,  including 
the  need  for  inclusion  of  confidentially,  integriy,  and  availability  policies  and  the  need 
for  confidence,  qualiy  and  robustness  of  securiy  features.  Mr  Re^er  also  gave  an 
overview  of  the  Mmimum  Securiy  Requirements  and  Ms  critique  of  the  Federal 
Oiteria. 

Finally,  he  provided  his  recommendation  for  a new  Commercial  Securiy  Profile  based 
on  the  CSS  Ftotection  Profile  wMch  reflects  the  original  Minimum  Securiy  Functional 
Requirements  (MSFR)  and  Minimum  Seciviy  Assurance  Requirements  0^  AR). 


Presentation  Two  « Kenneth  Cutler  - Vice  President, 
MIS  Training  Institute  


Mr.  Cutler  provided  general  comments  on  the  Commocial  Requirements  contained  in 
the  Federal  Criteria.  He  also  recommended  the  creation  of  additional  profiles  and  the 
deletion  of  superfluous  profiles. 

He  suggesting  adding  requirements  for  expert  systems  to  be  used  for  audit  analysis 
purposes  and  real-time  checks.  He  also  suggested  that  die  concq^t  of  **approval  authori- 
ties** should  be  considered. 

He  felt  that  supporting  availabiliy  is  important 
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Presentation  Three  - Ellen  O’Conner  of  the  internal 
Revenue  Service 


Ms.  O’Conner  works  for  the  Criminal  Investigation  Division  (CID)  of  the  IRS.  Ms. 
O’Cormer  described  CID  ^plications  that  manage  extremely  sensitive  (but  unclassi- 
fied) infonnation  such  as  case-  related  information,  informant,  undercover,  and  agent 
information. 

Ms.  O’Conner  explained  that  because  of  the  sensitivity  of  the  infonnation  that  is  being 
managed,  both  RBAC  and  row/record  access  controls  are  required.  She  would  like  the 
CSS  Protection  Profile  to  include  both  RBAC  and  row/record  access  controls. 
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CHAPTER  9 Label-Based  Protection 

Profiles 


Introduction 


The  F^eral  Criteria  Workshop  session  on  Label  Based  Protection  (LP)  Profile 
Comments  was  attended  by  thirteen  organizations  ranging  from  government,  such  as 
DOE,  Air  Force,  and  DIA,  to  industrial,  such  as  Grumman,  Boeing,  TIS,  Sparta,  CTA, 
and  individual  consultants. 

Discussion 


LP  Profiles  versus  TCSEC  Classes 

The  general  discussion  of  the  equivalence  of  the  LP  Profiles  and  the  corresponding 
Trusted  Computer  System  Evaluation  Criteria  (TCSEC)  classes  revealed  that  there  are 
many  areas  that  prevented  the  two  from  being  equivalent  Several  issues  would  prevent 
equivalency  between  the  LP  Profiles  and  the  TCSEC  classes: 

• Inclusion  of  terms  not  fully  defined 

• Use  of  products  previously  evaluated  that  would  not  meet  a requirement  without 
significant  change 

• Additicxi  of  wcvds  that  would  make  a requirement  weakCT  than  that  stated  in  the 
TCSEC 

• Addition  of  requirements  such  as  System  Management  and  Integrity 

• Inclusion  of  minor  modifications  (inclusion  of  an  “s**  at  the  end  of  a word)  that 
would  change  the  entire  meaning  of  a requirement 

• Inclusion  of  ill-defined  models  (ix.,  penetration  model  or  privilege  model). 
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In  several  places,  words  have  been  changed  and  thus  the  meaning  changes.  Examples  of 
this  include  the  use  of  “privileged”  and  “unprivileged”  in  place  of  the  words  “misted” 
and  “untnisted.”  Addidonally,  it  was  pointed  out  that  the  separation  and  repackaging  of 
assurance  added  to  the  change  in  requirements. 

Other  examples  of  changes  to  the  requirements  are  in  the  Least  Privilege  and  Label 
requirements.  Least  Privilege  expounds  on  the  requirement  and  changes  its  meaning. 
L^l  requirements  in  AC-S-t-  are  changed  by  requiring  labels  on  subjects  and  storage 
objects  r^er  than  all  resources.  This  change  does  not  support  the  basis  for  covert 
channel  analysis.  It  was  noted  by  one  vendor  of  an  A1  network  component  that  his 
produa  -v^’ould  not  meet  the  requirements  of  LP>4,  and  a vendor  of  a B2  product  indi- 
cated his  product  would  meet  the  functional  requirements  but  that  the  assurance  require- 
ments could  not  be  met 

Conclusion:  The  current  profiles  do  not  represent  the  same  requirements  as  defined  in 
the  equivalent  TCSEC  classes.  Backward  compatibility  should  be  based  on  the  TCSEC 
with  valid  clarifications  that  have  been  tested  over  the  last  10  years.  Evaluators  and 
vendors  should  have  the  opportunity  for  extensive  reviews.  The  TCSEC  was  mostly 
correct  in  this  respect,  while  the  Federal  Criteria  was  noL  The  TCSEC  should  be  used  as 
a basis  for  clarifying  the  requirements.  Due  to  time  constraints,  it  may  be  necessary  to 
explain  the  vetting  process  that  will  be  applied  to  ensure  compliance  with  TCSEC 
classes. 

Relationship  of  Components  and  Profiles 

There  was  considerable  discussion  on  the  relationship  of  components  and  profiles.  It 
was  felt  that  the  sq)aration  of  requirements  into  components  with  arbitrary  relationships 
added  to  the  differences  with  the  TCSEC.  The  dividing  of  Operational  Assurance  may 
not  have  been  necessary  if  a large  component  had  been  defined  to  maintain  the  relation- 
ship that  exists  in  the  TCSEC.  The  requirements  in  the  LP  Profiles  are  based  on  require- 
ments that  have  been  inaccurately  divided  into  components  which  when  put  back 
together  do  not  equal  the  TCSEC  classes. 

It  is  not  well  understood  whether  components  or  profiles  should  be  defined  first  Since 
the  vetting  involves  profiles,  it  was  felt  that  components  should  be  pulled  from  approved 
profiles  to  be  used  as  building  blocks.  Artificial  creation  of  components  was  viewed  as  a 
cause  of  die  LP  Profiles  being  diflerent  from  the  TCSEC  classes. 

Conclusion:  The  TCSEC  requirements  should  not  be  divided  into  arbitrary  components. 
After  the  profiles  have  been  vetted  to  be  equivalent  to  the  TCSEC  classes,  the  compo- 
nents could  be  identified  for  use  in  building  other  profiles.  If  other  components  are  still 
required,  then  new  profiles  should  be  made  based  on  those  new  components,  as  written 
and  without  extra  verbiage  or  refinements.  Words  used  in  components  should  match  the 
words  in  profiles  and  they  must  be  coirecL  Note:  There  may  need  to  be  a vetting  of  new 
components  from  new  profiles. 

Reference  for  Including  a Requirement 

It  was  discussed  that  there  needs  to  be  a set  of  guidebr;^*^^  to  define  worked  examples  that 
qualify  fm’  inclusion  as  a new  component  or  a new  requirement  in  the  criteria.  The 
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TCSEC  claim  was  that  there  were  three  wcMiced  examples  of  each  requirement; 
howevCT,  some  of  these  examples  were  not  readily  available  to  industry.  The  inclusion 
of  a wcKiced  example  must  have  wide  acceptance  over  multiple  communities  and  in 
industry.  Multiple  examples  of  implementations  by  vendors  must  be  provided  to  vali- 
date that  the  concept  is  reasonable  and  implementable.  Research  should  not  serve  as  the 
basis  for  inclusion;  however,  there  may  need  to  be  an  acceptance  of  a few  basic  research 
concepts. 

ConclusicHi;  For  inclusion  in  the  criteria,  the  requirement  must  exist  in  industry  (not  just 
academia),  multiple  examples  must  be  provided,  the  requirement  must  reflect  a reason- 
able view  of  the  technology  community  wide,  and  there  must  be  a balance  of  technical 
advancement  and  example  implementations. 

Need  for  Rationale  in  LP  Profiles 

This  discussion  focused  on  the  different  levels  of  detail  in  the  rationale  sections  of  the 
LP  and  CS  P^flles.  There  is  a great  deal  of  rationale  that  should  not  be  missed  to 
support  the  requirements  of  the  TCSEC.  It  was  noted  that  due  to  time  limits  this  ratio- 
nale could  not  be  included,  but  that  in  the  future  there  needs  to  be  consistency  in  the 
rationale  sections  of  the  profiles. 

Conclusion:  Rationale  is  totally  missing  from  the  LP  Profiles.  Well-written  rationale 
could  provide  effective  input  for  procurement  specifications.  The  rationale  should  iden- 
tify threats  and  Yellow  Book  English  rationale  types  of  things. 

Naming  Conventions 

The  current  naming  conventions  imply  a relationship  between  components  and  between 
profiles.  The  hierarchical  nature  of  the  TCSEC  classes  should  be  maintained,  but  that 
does  not  mean  that  there  is  a relationship  among  all  componmts  or  profiles. 

Conclusion:  The  naming  convention  should  be  changed  such  that  tho^  is  not  an  implied 
relationship  for  profiles  or  components.  One  way  to  do  this  is  to  use  the  names  of  the 
TCSEC  classes,  such  as  Controlled  Access  Protection,  which  could  be  called  **LP- 
CAP.”  The  profile  description  should  define  any  relationship  or  inclusion  of  other  profile 
requirements. 


Summary 


The  existing  LP  Profiles  do  not  represent  the  same  set  of  requirements  that  exist  in  the 
TCSEC  classes  B1  through  Al.  Because  of  time  constraints,  it  may  be  necessary  to  use 
the  exaa  TCSEC  language  in  the  profiles  to  allow  for  a vetting  of  the  profile  to  update 
them  with  evaluation  case  law  that  has  evolved  over  the  past  decade  of  experience.  A 
multidiscipline  group  of  vendors,  evaluators,  and  users  should  update  the  pofiles  over 
time  to  enhance  the  requirements  to  the  level  of  practice.  This  process  would  then 
produce  new  profiles  that  relate  to  the  TCSEC  as  well  as  provide  an  exact  copy  of  the 
TCSEC  requirements. 
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The  language  and  description  of  profiles  need  to  be  further  refined  to  ensure  that  the 
relationship  between  components  and  profiles  is  precise  and  well  understood.  The 
process  of  profile  development  and  vetting  must  be  defined  so  that  it  is  well  understood 
by  the  vendor  community.  Until  the  vetting  process  is  well  defined,  the  language  of  the 
TCSEC  should  be  maintained  in  the  equivalent  LP  Profiles. 
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CHAPTER  10  Intemational 

Harmonization 


Introduction 


This  workshc^  session  covered  the  stq)s  for  moving  fcrward  from  the  draft  Federal 
Criteria  (FC)  to  intemational  harmonization.  It  was  held  in  the  context  of  the  announce- 
ment that  the  governments  of  North  America  (NIST,  NS  A,  and  the  Canadian  CSE)  have 
entered  into  an  agreement  with  the  European  Community  (United  Kingdom,  France, 
and  Germany)  to  work  over  the  next  year  towards  a Common  IT  Security  Criteria.  A 
Common  Criteria  Editorial  Board  (CCEB)  has  been  established,  though  at  the  time  of 
the  workshop  it  had  not  yet  met  In  this  session,  all  six  members  of  the  Editorial  Board 
were  present  as  participants  in  the  discussions.  They  are: 

Paul  Cormier,  Canada  (Communication  Security  Establishment) 

Chris  Ketley,  UK  (Communications  Electronics  Security  Group) 

Yvon  Klein,  France  (Central  Security  Service  for  Information  Systems) 

Hartwig  Kreutz,  Germany  (German  Information  Security  Agency) 

Mario  Unto,  US  (National  Security  Agency) 

Eugene  Troy,  US  (National  Institute  of  Standards  and  Technology) 

Approximately  25  other  individuals  were  present,  including  representatives  from 
various  US  government  agencies,  other  European  organizations,  and  several  representa- 
tives of  muldnational  computer  product  suppliers. 


Initial  Topic  Issues 


The  PC  states  that  intemational  harmonization  of  criteria  and  mutual  recognition  of 
evaluations  are  objectives.  The  basic  question  that  must  be  asked  is  whether  the  FC 
wort:  has  advanced  or  hindered  intemational  harmonization.  A second  and  related  ques- 
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don  is  what  is  the  path  to  achieving  harmonization  from  this  point  It  is  generally  agreed 
that  we  all  want  to  be  pointed  toward  international  convergence  in  this  area,  yet  how  do 
we  achieve  that  while  saving  those  things  in  the  individual  criteria  (e.g.,  TCSEC, 
rrSEC.  FC)  that  the  nations  believe  are  important?  Numerous  comments  were  received 
that  generally  discussed  issues  related  to  harmonization.  The  topics  below  were  derived 
from  an  analysis  of  those  comments  in  the  light  of  the  impending  Common  Criteria 
project 

1.  What  are  Potential  Roadblocks  to  Harmonization? 

The  key  issues  about  harmonization  identified  in  the  FC  comments  deal  with: 

a.  Assuranca  Approaches 

What  are  the  elements  of  assurance,  the  process  of  gaining  confidence  about  the  security 
frinctions  in  the  product?  The  Europeans  have  advanced  the  twin  notions  of  effective- 
ness  and  correctness  in  the  ITSEC,  while  the  US  has  divided  the  assurance  process  into 
development  and  evaluation  assurance.  Is  there  a way  of  converging  these  two 
^>proaches,  and  do  they  even  cover  the  same  thing?  It  may  be  that  the  differences 
between  them  are  more  perceived  than  real.  The  issues  may  be  more  of  form  and  style, 
rather  than  substance. 

b.  Protoction  Profiles  in  the  FC  versus  Security  Targets  and  Functionality  Classes 
In  the  ITSEC 

Some  convergence  in  the  area  of  security  targets  has  already  been  seen  in  the  workshop. 
There  is  im  indication  of  this  prospect  for  convergence  in  the  comments  becaii:^-  in  the 
draft  FC  protection  profiles  were  not  clearly  enough  related  to  security  targets  and  func- 
tionality classes.  It  seems  to  be  becoming  much  clearer  that  in  general,  protection 
profiles  can  usefully  be  viewed  as  user  requirements  while  security  targets  are  to  be  seen 
as  engineering  spe^cations.  It  is  also  clearer  that  protection  profiles  may  not  always  be 
needed  for  product  evaluations. 

c.  Intomatbnal  Profiles 

A number  of  FC  comments  focused  concern  on  the  prospect  of  further  fragmenting  the 
international  IT  product  market  via  free  creation  of  a spate  of  protection  profiles.  There 
was  also  a sgnificant  amount  of  concern  in  the  comments  over  the  implication  of  export 
laws  with  respect  to  products  built  to  protection  profiles.  The  reviewers  generally 
seemed  to  accq)t  that  it  must  be  left  to  the  natioiial  government  agencies  to  decide  the 
IT  security  requirements  for  their  governments  and  state  them  to  the  suppliers.  Several 
reviewers  advanced  the  notion  of  going  beyond  national  standardization  (or  vetting)  of 
profiles  to  do  so  on  the  international  level,  although  it  was  noted  that  it  is  difficult  to  see 
how  that  could  work.  There  is  clearly  an  expressed  need  to  converge  with  other  interna- 
tional standardization  work,  such  as  ISO  SC27.  Questions  that  arose  m this  connection 
are  the  following:  How  do  you  harulle  international  development  and  vetting  of  protec- 
ti  ^'.  profiles?  Who  is  a legitimate  developer  of  profiles  under  such  a system?  Who  will 
en^nisted  with  the  duty  of  deciding  whether  profiles  are  proper?  How  can  profiles 
evGive  over  time  to  keep  pace  with  requirements  and  technology? 
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2.  Phase-in  to  Harmonization 

The  key  concerns  about  the  process  of  achieving  harmonization  identified  in  the  FC 
comments  and  in  later  informal  comments  received  on  the  Common  Criteria  project 
deal  with: 

a.  What  Should  be  the  Steps  to  Harmonization? 

Some  comments  expressed  concern  about  the  inherent  feasibility  of  achieving  harmoni- 
zation. It  was  noted  that  there  are  four  IT  security  criteria  now  in  existence,  in  varying 
degrees  of  completion.  The  concern  was  how  we  can  move  from  that  posture  to  a single 
criteria  that  can  be  agreed  upon  by  a large  number  of  nations.  A proposal  has  been  made 
that  the  CCEB  should  focus  its  work  on  the  common  core,  the  toolset,  and  not  on  devel- 
oping or  agreeing  on  profiles. 

b.  How  Should  Users  & Suppliers  Proceed  during  Convergence? 

This  is  a concern  that  was  expressed  in  the  comments  with  respect  to  the  phase-in  of  the 
FC  which  has  even  more  ^iplicability  to  the  Commcm  Criteria  work.  There  is  a concern 
whether  there  are  some  specific  things  that  we  can  do  to  help  users  and  suppliers  in  the 
interim.  It  was  noted  that  the  UK  and  Germany  have  experienced  this  problem  of  having 
their  own  criteria  and  then  phasing  into  use  of  the  ITSEC.  There  is  a need  to  plan  care- 
fully for  the  transition.  One  sillier  noted  that  suppliers  will  tend  to  respond  to  these  in- 
flux requirements  by  building  their  products  more  generally  to  encompass  multiple  sets 
of  requirements. 

c.  How  Should  Backward  Compatibility  with  National  Criteria  be  Handled? 

This  question  is  closely  related  to  the  previous  quesdoTL  Comments  in  this  area  were 
expressed  mostly  as  generalized  concerns,  iK)t  so  much  with  protecting  the  criteria 
themselves  but  with  the  supplier  and  usct  investments  in  prior  standards.  In  the  interna- 
tional arena,  it  was  noted  that  national  laws  or  regulations,  such  as  those  of  Germany, 
have  an  impact  because  they  specify  adherence  to  particular  criteria. 

d.  How  Does  this  Work  on  Common  Criteria  Relate  to  ISO  SC27? 

In  the  same  context,  other  reviewers  were  concerned  about  how  to  handle  the  issue  of 
achieving  an  ISO  standard  that  incorporates  the  FC  work.  This  question  is  now  extended 
to  the  Common  Criteria  work.  The  question  boils  down  to:  How  can  ISO  SC27  relate  to 
the  Common  Criteria  development  process?  How  will  the  Editorial  Board  and  its  spon- 
soring nations  make  their  work  applicable  and  acceptable  in  ISO? 


Presentation  by  Julian  Straw,  SISL  (UK) 


Mr.  Straw,  a senior  evaluator  for  one  of  the  UK  commercially  licensed  evaluation  facili- 
ties, made  a cautiously  optimistic  presentation  on  the  FC  versus  the  ITSEC,  which  has 
specific  application  to  the  Common  Criteria  work.  He  viewed  the  FC  work  as  providing 
many  new  ideas  and  material  that  are  supportive  of  harmonization. 

Mr.  Straw  identified  the  following  main  issues  that  need  to  be  dealt  with  in  achieving 
international  harmonization.  Several  of  these  were  also  covered  in  his  written 
comments.  Accordingly  they  will  not  be  gone  into  in  detail  here. 
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1.  D:^mmon  Criteria 

The  FC  has  helped  sort  out  the  difTerences  among  the  current  criteria  by  moving  in  the 
direction  of  rapport  He  cited  the  separation  of  functionality  and  assurance,  the  use  of 
the  security  taiget  as  a basis  for  the  notion  of  a protection  profile,  and  the  accq)tance  of 
the  notions  of  correctness  and  effectiveness  as  expressed  in  high-level  requirements.  He 
noted  that  there  are  indeed  commonalities  between  the  ITS£C*s  correcmess/effective- 
ness  and  the  PC’s  development/evaluation  assurance  approaches,  but  pointed  out 
several  specific  differences  in  application  of  these  requirements  at  various  levels  on 
each  side.  He  was  very  concerned  with  the  FC  notion  of  dependencies,  and  felt  they 
would  become  a big  issue  because  there  is  no  common  agreement  on  what  they  are  or 
how  they  are  identified  and  expressed. 

2.  Evaluation  Method 

Mr.  Straw  noted  there  is  some  experience  with  using  a multi-national  criteria  in  Europe. 
However,  he  said  there  have  alre^y  been  instances  where  evaluators  and  certification 
bodies  in  Germany  and  the  UK  have  interpreted  parts  of  the  ITSEC  differently.  This 
makes  it  clear  that  a single  set  of  criteria  among  nations  is  not  enough  in  itselfi  There  is 
also  a need  for  a common  evaluation  method  as  a basis  for  harmonization,  to  ensure  that 
developers  and  evaluators  do  the  same  things. 

3.  Product  Certification  Process 

Mr.  Straw  pointed  out  the  central  importance  of  evaluation  results  acceptab  k one 
country  also  being  acceptable  in  another  country.  He  identified  two  levels  c rr^utual 
acceptance:  accq)tance  of  the  results  of  evaluation,  and  acceptance  of  certificates 
issued.  These  can  be  considered  somewhat  indq)endently.  For  example,  it  is  possible  for 
aprodua  evaluation  report  to  be  passed  from  one  country  to  another,  with  the  certifying 
body  in  the  second  indq)endent]y  deciding  whether  it  wants  to  award  the  product  a 
certificate  based  on  acceptance  of  the  evaluation  report  However,  he  said  that  the 
second  level  of  mutual  acceptance,  that  of  a second  national  certifying  body  accepting  a 
certificate  issued  by  the  first  should  be  the  objective.  If  we  can  trust  one  another  in  both 
the  evaluation  and  certification  processes,  it  will  minimize  the  amount  of  duplicated 
effort 

4.  Why  Do  We  Want  to  Achieve  Harmonization? 

Mr.  Straw  stated  that  there  are  four  main  reasons  for  seeking  harmonization  of  criteria 
and  evaluation  methods: 

• It  is  easier  for  those  who  are  buying  products.  When  products  are  evaluated  under 
different  criteria  it  is  hard  for  the  buyers  to  determine  the  differences  and  how  they 
should  respond. 

• It  is  much  cheaper  and  quicker  for  suppliers  to  comply.  Who  would  voluntarily  want 
to  undergo  two  evaluations  in  two  countries?  It  is  far  more  economical  to  do  just  one 
evaluation. 

• The  criteria  can  be  improved  by  taking  the  best  things  from  each.  None  are  perfect, 
yet  each  nation  has  the  same  problems  to  solve  via  security  criteria. 
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• There  will  be  an  improved  basis  for  comparing  security  requirements  between  coun- 
tries and  between  products. 

5.  What  We  Need  to  Move  Forward. 

Mr.  Straw  felt  that  the  following  things  are  needed  to  move  fc^ard  towards  harmoniza- 
tion. 

• We  need  some  product  to  evaluate  as  part  of  the  process  of  trying  out  the  criteria 
concepts.  The  trial  evaluation  should  be  done  in  a common  way,  against  a product 
with  any  useful  set  of  security  functionality. 

• We  need  a body  to  decide  whether  evaluation  of  a particular  product  or  product  type 
is  worthwhile.  Under  the  FC,  this  is  accomplished  via  the  vetting  of  a protection 
profile.  Under  the  ITSEC,  this  is  usually  achieved  by  a certification  body  deciding 
whether  a particular  security  target  is  suitable  for  evaluation,  as  well  as  by  evaluators 
looking  at  it  for  consistency. 

• Criteria  must  overtly  cover  both  correcmess  and  effectiveness.  Does  the  product 
work  as  specified?  Does  it  do  what  it  is  supposed  to  do  by  satisfying  the  objectives 
as  stated  in  the  protection  profile  and/or  security  target? 

• Criteria  must  cover  both  commercial  and  military  requirements.  He  is  not  totally 
convinced  whether  there  is  a commercial  requirement  for  evaluation.  Evaluation  of 
conunercially-oriented  products  has  not  caught  on  well  due  to  the  costs  involved. 

• Criteria  must  be  comprehensible.  Complaints  have  been  received  that  the  ITSEC  has 
too  many  levels  (6)  of  assurance.  The  FC  has  28  separate  assurance  components  that 
must  be  built  into  protection  profiles,  with  no  fixed  levels  that  must  be  used.  He  is 
not  looking  forward  to  the  task  of  explaining  this  variety  to  people  submitting  their 
products  for  evaluation.  Therefore  the  area  of  building  a straightforward  and  useful 
set  of  profiles  is  quite  importaiu.  Try  to  keep  it  simple. 


Presentation  by  David  Chizmadia,  NSA 


Mr.  Chizmadia,  a former  evaluator,  presented  ideas  on  how  to  reconcile  the  ITSEC’s 
effectiveness/correemess  with  the  EC’s  development/evaluation  assurance. 

He  provided  two  working  definitions  for  discussion.  Correcmess  asks,  **Does  the 
product  do  the  thing  (security  function)  right?**  Effectiveness  is  oriented  towards  an 
assurance  objective  by  asking,  *Does  the  product  do  the  right  thing  (security  function)?** 
Effectiveness  then  becomes  a judgment  ^ut  the  environment  and  the  product 

Part  of  his  work  has  been  oriented  towards  finding  some  policy  oriented  motivation  for 
assurance.  In  his  view,  policy  is  just  about  how  the  system  makes  information  available. 
Security  objective  is  a better  term  than  security  policy,  because  it  helps  avoid  confusion. 
He  states  that  effectiveness  and  correctness  should  be  defined  at  the  same  level  of 
abstraction  as  other  kinds  of  **security  policy-based  objectives,**  including  integrity, 
accountability,  confidentialiQr,  and  availability.  By  doing  so,  you  now  have  a way  of 
tracing  firom  high-level  policy  objectives  to  what  specifically  is  being  asking  for.  You 
may  now  identify  assurance  objectives  based  on  policy,  in  the  same  way  as  you  identify 
the  objectives  for  the  security  policy-based  requirements.  These  two  can  then  be 


FEDERAL  CRITERIA  WORKSHOP  PROCEEDINGS 


57 


International  Harmonization 


possibly  indq)endenL  In  this  way,  aU  of  the  requirements  for  a product  must  be  reflected 
in  the  c^jectives  and  therefore  must  be  soundly  based  on  policy. 

Following  this  proposed  approach,  the  user  has  a much  better  ability  to  decide  what  is 
needed  and  can  then  map  it  down  to  specific  requirements.  Independent  of  security 
objectives,  assurance  objectives  may  also  be  stated.  In  this  way,  you  can  do  assurance 
independent  of  security  objectives. 


General  Discussion 


A general  discussion  followed  the  two  presentations,  generally  based  on  the  set  of  topics 
given  originally  under  **potential  roadblocks**  and  ^‘phase-in  to  harmonization.** 

1.  What  are  Potential  Roadblocks  to  Harmonization? 

The  key  discussion  points  centered  on  the  potential  roadblock  topic  issues  raised  at  the 
start  of  the  session: 

a.  Assurance  Approaches 

Discussion  continued  about  some  of  the  incompatibilities  between  ITSEC  and  FC  assur> 
ance  approaches,  particularly  effectiveness/correctness  vs.  development/evaluation.  As 
discussion  proceed,  it  appeared  that  incompatibilities  remain  to  be  worked  out,  but 
these  are  probably  less  a problem  than  initially  thought  One  of  the  key  differences  is 
that  some  of  the  effectiveness  work,  such  as  suitability  of  functionality,  is  done  during 
profile  construction  and  analysis.  A European  security  expert  noted  that  ease  of  use  is 
actually  handled  better  in  the  FC  than  in  the  ITSEC,  that  it  is  more  well  rounded.  It  is 
treated  as  part  of  functionality  instead  of  assurance.  He  also  noted  that  strength  of  mech- 
anism is  burning  less  important  in  the  ITSEC  as  European  evaluators  gradually  try  to 
refine  what  they  are  trying  to  test  the  strength  of.  In  his  view,  other  effectiveness  factors 
may  be  in  the  FC,  but  they  are  generally  found  only  at  the  higher  levels,  while  in  the 
ITSEC  they  are  applicable  to  some  degree  to  all  levels.  He  gave  as  one  example  penetra- 
tion analysis,  where  it  is  not  used  until  LP2  while  under  the  ITSEC  it  is  done  at  the 
lowest  levels. 

The  general  argument  about  how  and  why  assurance  is  gained  about  a product’s  security 
functions  was  raised.  This  was  coupled  with  discussion  about  why  overt  assurance  via 
evaluations  should  be  sought  This  issue  is  important  to  the  harmonization  work, 
because  the  European  Community  seems  to  be  strongly  vested  in  the  notion  of  produa 
and  system  security  evaluations  for  both  government  and  private  enterprise.  It  was 
noted  that  assurance  that  a product  works  as  advertised  is  commonly  expected,  but  in 
the  non-military  world  the  notion  of  third-party  evaluation  as  its  source  is  seldom  volun- 
tarily considered.  One  individual  raised  the  notion  that  the  intelligence  community  has 
national  risk  assessment  documents  that  link  risks/objectives  of  the  organizations  into 
TCSEC  assurance  levels.  He  noted  that  they  tend  not  to  publicize  these  documents — 
they  are  internal  for  accreditors  use.  The  end  result  is  tlm  assurance  tends  to  be  a 
distress  purchase — because  users  are  told  to,  not  because  they  want  to. 

It  was  agreed  there  is  a range  of  ways  by  which  people  gain  assurance  about  what  they 
buy  or  use,  whether  it  is  cars,  seatbelts  or  computers.  The  formalized  evaluation  process 
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is  one  of  these  ways  that  the  military  and  intelligence  communities  have  found  impor- 
tant to  them.  It  is  clear  that  as  of  this  time,  commercial  users  do  not  see  the  same  kind  of 
value  in  that  process,  and  tend  to  do  the  assurance  work  themselves  in  various  ways.  It 
may  be  that  work  needs  to  go  forward  on  finding  suitable  and  p)Ossibly  standardized 
ways  for  the  private  world  to  achieve  assurance  about  security  products  short  of  lengthy 
and  costly  third-party  formal  evaluations.  This  whole  area  seems  to  be  tractable  as  long 
as  we  continue  to  understand  more  and  mcHC  on  what  each  side  is  intending. 

b.  Protection  Profiles  in  the  PC  versus  Security  Targets  and  Functionality  Classes 
in  the  ITSEC 

The  discussion  indicated  that  most  people  did  not  find  inh^ent  conflict  between  the 
notions  of  protection  profile  and  security  target,  when  each  is  properly  understood. 
There  was  growing  acceptance  of  the  notion  that  the  concepts  tend  to  be  mutually 
sui^rtive.  The  discussion  pointed  up  the  need  for  a far  better  explanation  of  the  joint 
roles  of  the  protection  profile  and  security  target  and  how  the  two  should  be  used 
together  in  connection  with  product  development  and  evaluation. 

One  big  remaining  area  of  disconnection  centred  around  the  FC  notion  of  depends - 
cies.  Interaction  between  product  elements  is  treated  in  the  ITSEC  under  binding  of 
functionality.  As  such,  it  is  left  up  to  those  preparing  security  targets  and  to  the  evalua- 
tors. This  was  noted  by  some  participants  as  a possible  weakness  in  the  ITSEC.  It 
remained  clear  that  the  treatment  of  dependencies  in  the  FC  was  well  below  what  many 
viewed  as  needed.  The  process  of  identifying  dq)endencies  still  seemed  overly  complex 
to  the  participants,  and  it  was  unclear  how  this  issue  should  be  treated  in  the  Common 
Criteria. 

c.  International  Protection  Profiles 

Perhaps  the  laigest  single  area  of  discussiem  in  the  session  had  to  do  with  the  notion  of 
international  protection  profiles.  The  issues  raised  covered  all  the  points  initially  identi- 
fied. 

There  was  deep  concern  over  the  potential  proliferation  of  protection  profiles  interna- 
tionally. One  speaker  from  the  supplier  community  even  suggested,  with  support  from 
other  speakers,  that  the  success  of  the  Common  Criteria  venture,  from  the  point  of  view 
of  actually  getting  products  out  in  the  marketplace,  is  going  to  be  inversely  propoiional 
to  the  number  of  profiles  available.  He  stated  the  reason  for  that  is  the  market  for  secu- 
rity products  is  actually  very  weak.  There  are  no  security  vendors  that  will  claim  there  is 
anyone  beating  down  their  door.  He  expressed  hope  that  with  internationalization  the 
wcx-ld  will  become  one  marketplace.  A number  of  diffonm  profiles  will  fragment  the 
market  again,  and  then  there  will  be  a bunch  of  little  weak  markets  instead  of  one  strong 
one. 


AiK>ther  supplier  expressed  support  for  the  effort  because  there  would  be  fewer  basic 
requirements,  and  all  of  them  generated  from  a Common  Criteria  which  would  be  used 
as  the  basis.  He  was  concerned  about  one  possible  scenario  with  multiple  profiles.  Say 
his  company  decided  to  build  a product  to  a given  profile  and  have  it  evaluated  (based 
on  a business  decision)  and  then  later  perceived  the  incremental  market  going  for 
another  similar  profile.  He  wanted  to  know  whether  an  incremental  evaluation  could  be 
done  against  the  differences  or  would  they  have  to  do  the  whole  evaluation  all  over 
again  and  double  their  costs. 
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The  issue  of  international  protection  profiles,  from  the  viewpoint  of  how  to  standardize 
them,  who  develops  them,  etc.,  was  discussed,  it  was  noted  that  this  problem  has  begun 
to  be  looked  at  in  the  ISO  SC27  context  An  initiative  was  also  started  in  the  European 
Community  to  develop  predefined  functionality  classes  for  vertical  industry  segments. 
A European  Community  (EQ  research  task  was  funded  to  identify  a dozen  functionality 
classes  for  the  commercial  sector.  No  results  have  yet  been  published  from  the  study. 
There  was  no  resolution  as  to  the  mechanics  of  the  processes  needed  to  arrive  at  interna- 
ticml  protection  profiles.  In  general,  suppliers  want  to  see  the  adveuit  of  these  profiles  to 
make  their  life  easier.  One  point  that  was  brought  up  is  that  such  profiles  should  not  be 
highly  specific  in  their  requirements. 

Aix)ther  point  that  was  raised  is  if  we  gently  phase  it  in  (taking  into  account  what 
everyone  wants)  we  never  will  achieve  the  goal — it  will  take  too  long.  The  process  is  so 
large  and  important  that  some  gioups/agencies/govemments  will  have  to  step  up  and 
dictate  what  they  want  to  see.  One  speaker  noted  that  it  ^^/ill  be  up  to  governments  to 
come  up  with  the  first  set  of  international  protection  pro>;ir:3  for  it  to  happen  in  our  life- 
time. Who  standardizesA^ets/registers  profiles  may  be  a consortium  of  interested 
government  bodies.  This  is  the  only  way  to  do  it  in  a short  time. 

One  evaluator  pointed  out  the  great  degree  of  difficulty  that  has  already  begun  over 
gaining  consensus  that  LP-1  represents  the  same  thing  as  B 1.  He  felt  that  based  on  that 
experience  it  is  not  likely  that  international  profiles  will  gain  easy  acceptance  in  the 
community — there  are  too  many  disparate  viewpoints  and  vested  interests  for 
consensus.  He  stated  that  a set  of  international  profiles  is  desirable  but  not  likely. 

Several  participants  noted  that  national  laws  may  also  have  an  effect  on  the  develop- 
ment of  international  profiles  and  on  the  proqrects  for  international  harmonization.  Two 
areas  were  pointed  up,  export  restrictions  and  encryption  mechanisms.  It  was  noted  that 
export  licenses  are  possible  for  B3  and  higher  products,  but  that  this  resuiction  was  still 
burdensome.  Until  these  issues  are  clearly  resolved  among  narinral  goverrcments,  and 
especially  the  cryptologic  authorities,  there  is  little  prospect  i r ntemati.v'iiai  trade  in 
high-security  computing  devices. 

The  issue  of  including  encryption  technology  in  evaluatable  products  arose.  It  was 
observed  by  several  that  there  is  little  prospect  for  network  or  disuibuted  security 
without  encryption.  There  was  a discussion  whether  the  criteria  were  to  be  expanded  to 
include  evaluation  of  encryption  devices.  One  evaluator  said  that  what  one  does  to  eval- 
uate encryption  devices  and  algorithms  is  much  different  than  what  is  described  in  any 
public  criteria.  It  was  pointed  out  that  evaluation  of  products  which  contain  an  imple- 
mentation of  encryption  mechanisms  was  different  ^m  evaluating  the  mechanisms 
themselves,  which  must  be  considered  separately  by  cryptologic  authorities.  The  quality 
of  the  implementation  or  the  need  for  it  are  properly  subject  to  IT  security  evaluation, 
while  the  encryption  techniques  themselves  are  not  It  was  clear  that  this  is  still  a fuzzy 
issue  which  needed  to  be  tackled  by  the  national  authorities. 

2.  Phase-ln  to  Harmonization 

The  key  discussion  points  about  the  process  c t achieving  harmonization  were: 
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a.  What  Should  be  the  Steps  to  Harmonization? 

The  Ediuml  Board  memb^  and  others  pointed  out  that  the  North  American  and  Euro- 
pean governments’  planned  steps  are  already  becoming  somewhat  clear,  even  though 
detailed  planning  work  has  not  yet  been  done.  (At  the  time  of  the  workshop,  the  Edito- 
rial Board  had  not  yet  met)  The  role  of  the  Editorial  Board  to  come  into  agreement  on 
the  structure  of  the  aligned  criteria  and  to  orchestrate  its  creation  was  discussed. 

Internationally  representative  technical  groups  of  security  experts  will  be  used  to 
support  the  work,  although  their  specific  roles  in  the  project  have  not  yet  been  estab- 
lished. Technical  support  groups  will  work  alongside  the  Editorial  Board  and  will  be 
tasked  to  do  specific  things.  This  covers  whatever  needs  to  be  done — ^writing,  research, 
etc.  This  brings  in  an  opportunity  for  broader  representation.  The  technical  support 
groups  do  not  have  to  be  exclusively  composed  of  government  employees  or  contractors 
of  the  various  countries,  some  could  be  from  the  user  community  cm’  supplier  commu- 
nity. There  are  no  ground  rules  yet 

One  question  arose  as  to  whether  technical  groups  could  be  used  to  capture  and  refine 
conunonly  seen  protection  profiles,  security  targets,  or  functionality  classes  that  have 
been  created  under  the  ITSEC  or  FC.  It  was  agreed  this  would  be  a valid  use  of  tech- 
nical groups  and  an  especially  productive  place  for  suppliers  and  users.  However,  some 
of  the  Editorial  Board  members  pointed  out  that  the  Board  has  a very  short  time  in 
which  to  operate,  and  that  it  would  be  better  to  concentrate  on  developing  the  tools  for 
building  the  profiles  rather  than  on  develqring  the  profiles  themselves.  There  could  be 
some  parallel  effort,  but  there  is  a work  factor. 

In  discussing  the  role  of  the  Editorial  Board,  the  notion  of  a common  core  of  tools  arose. 
One  observer  stated  that  this  workshop  has  already  had  an  impact  on  the  underlying 
assumptions  and  semantic  differences — ^it  is  becoming  ever  more  clear  that  the  issues 
are  semantic  more  than  differences  in  what  we  are  trying  to  do.  We  have  six  agencies 
from  five  countries  represented  on  the  Editorial  Board,  all  who  have  the  same  problem 
to  solve.  They  have  all  tried  individually  to  solve  the  problem.  It  appears  that  we  can 
draw  the  circle  quite  large  around  the  requirements  of  the  various  IT  security  constitu- 
encies to  include  them  all. 

b.  How  Should  Users  & Suppliers  Proceed  during  Convergence? 

One  supplier  representative  suggested  that  research  on  market  segments  found  that  most 
users  needed  essentially  the  same  things.  Thoefore  there  should  not  be  that  many 
different  protection  profiles,  regardless  of  harmonization.  The  governments  want  to  buy 
Commercial  Off-the-Shelf  (COTS)  products.  He  felt  that  no  supplier  is  going  to  produce 
four  different  multi-level  products  for  government  use.  Perhaps  there  will  be  a high  one 
and  a low  one — two  at  the  most  Therefore,  suppliers  will  tend  to  proceed  along  paths 
they  already  know,  to  build  to  known  requirements  that  have  already  come  from  govern- 
ments and  user  communities.  They  will,  howevo-,  seek  to  generalize  their  products  as 
much  as  possible,  to  include  a wide  range  of  security  features. 

Another  participant  stated  that  there  still  will  be  differences  at  the  national  level  as  to 
what  is  required.  The  coming  to  a set  of  international  profiles  will  be  a long  and  difficult 
one.  Perh^  the  suppliers  will  have  to  combine  the  more  stringent  requirements  from 
the  different  countries  to  arrive  at  an  international  profile.  The  supplier  will  have  to  take 
the  least  upper  bound.  The  criteria  would  then  be  in  excess  of  requirements  for  each 
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country  in  order  to  meet  all  requirements  for  each  country.  There  would  also  be  a 
problem  if  the  requirements  are  in  conflict  with  one  another.  He  felt  the  cost  for  building 
to  an  envelope  such  as  that  would  not  be  as  great  as  that  for  going  through  several  eval- 
uations. 

c.  How  Should  Backward  Compatibility  with  National  Criteria  be  Handled? 

One  point  in  this  area  that  was  brought  up  was  the  RAMP  process.  There  was  consensus 
that  this  process  has  fully  demonstrated  the  value  of  the  notion  of  development  assur- 
ance and  should  be  retained  in  future  criteria.  It  does  not  yet  exist  in  the  ITSEC, 
although  there  have  been  discussions  about  including  it. 

d.  How  Does  this  Work  on  Common  Criteria  Relate  to  ISO  SC27? 

Several  speakers  noted  that  the  long  term  objective  of  the  Common  Criteria  project 
must  be  to  fit  its  work  into  ISO  and  achieve  an  international  criteria  standard.  In  addi- 
tion, people  noted  that  standardized  requirements  profiles  for  various  products  already 
are  coming  out  of  the  ISO  environment,  wimess  ISO  7498-2  for  security  of  open  system 
interconnection.  But  a transition  plan  needs  to  be  woriced  out,  which  may  be  a common 
criteria  agreed  to  internationally.  It  was  noted  that  ISO  tends  not  to  do  oiiginal  work,  but 
to  worit  on  existing  documents  that  have  been  tabled. 

Other  speakers  identified  several  other  related  international  standards  activities  in  the  IT 
security  area  in  addition  to  ISO  SC27.  These  include  the  European  Computer  Manufac- 
turers Association  (ECMA)  TC-36,  Portable  Operating  System  Interface  for  Computer 
Environments  (POSIX),  Open  Software  Found^on  (OS^  and  X/Open.  There  will  be  a 
difficulty  converging  all  these  with  the  Common  Criteria  effort,  as  the  only  common 
forum  is  ISO,  which  tends  to  operate  slowly. 

X/Open  activities  were  described  as  especially  germane  to  the  Common  Criteria  project. 
XA^)en  is  intending  to  define  a common  set  of  security  functionality,  and  they  intend  to 
provide  a branding  scheme  so  that  a vendor  that  claims  compliance  will  be  able  to 
execute  against  a test  suite  and  get  a brand.  There  is  the  prospect  that  a large  number  of 
users  may  be  h^y  with  the  X/Open  brand  as  demonstration  of  needed  security  features 
and  assurance,  which  will  further  reduce  the  market  for  evaluation.  X/Open*  *s  publica- 
tion of  security  standards  is  temporarily  on  hold  while  they  look  at  the  implications  of 
security  services,  APIs  and  disoibuted  security. 


Moderator  Conclusions 


This  session  has  demonstrated  that  the  gap  between  criteria  is  not  so  great  as  some  may 
believe. 

• In  the  area  of  assurance,  there  has  developed  a basis  for  discussion  to  resolve  the 
qiparent  differences  between  effectivene^correctness  and  development/evaluation 
assurance.  The  question  about  how  to  resolve  the  ITSEC's  fixed  assurance  levels 
versus  the  FC*s  more  flexible  approach  of  protection  profile  specification  not  dq)en- 
dent  on  T-levels  remains  qpeiu 

• Regarding  protection  profiles  versus  security  targets,  the  eariier  perceived  differ- 
ences were  mainly  due  to  a lack  of  doctrine  in  the  FC  about  how  the  two  relate. 
Further  discussions  have  demonstrated  that  the  two  are  not  in  conflict,  but  rather  can 
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woric  together  nicely.  However,  the  protection  profile  development  and  approval 
process  does  have  implications  for  assurance  harmonization,  because  it  subsumes 
some  of  the  processes  related  to  effectiveness.  This  issue  needs  substantial  clarifica- 
tion. Also,  the  notion  of  dependencies,  introduced  in  the  FC,  needs  to  be  developed 
in  significantly  greater  detail  regarding  the  method  of  identification  and  the  manner 
of  expressing  them. 

• Internationally-accepted  protection  profiles  appear  feasible  on  a limited  basis  for 
very  common  sets  of  requirements.  The  MSFR  work  has  had  strong  impact  cm  both 
ECMA  and  Japan,  and  could  become  the  nucleus  of  work  cm  the  first  international 
profile.  There  is  great  concern  over  the  process  of  forming  the  profiles  and  gaining 
rqrproval  for  them.  There  is  also  concern  about  the  prospect  for  proliferation  of  many 
profiles,  which  may  have  negative  market  effects. 

• The  Ccxnmon  Criteria  Editorial  Board’s  early  activities  in  charting  a course  to  align- 
ment will  be  scrutinized  closely,  especially  from  the  viewpoint  of  external  (user  and 
IT  product  supplier)  participation  in  the  process.  The  Board  should  fcmus  on  devel- 
oping the  tools  for  the  criteria,  not  on  developing  profiles. 

• The  Common  Criteria  project  must  take  into  consideration  the  other  international 
standardization  activities  which  are  going  cm  in  IT  security.  In  particular,  the  project 
must  interact  closely  with  ISO  SC27,  which  is  the  logical  point  of  convergence  of  all 
oth^  intoests  beyond  North  American  and  European  governmental  agencies.  Ulti- 
mately, an  ISO  standard  criteria  is  needed,  and  ISO  is  also  the  likely  candidate  for 
vetting  and  registry  of  international  protection  profiles. 
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Future  Work  with  the 
Federal  Criteria  for  Input 
into  the  Common  Criteria 
Editorial  Board 


Overview 


As  a result  of  the  comments  received  on  the  first  draft  of  the  Federal  Criteria,  and 
the  input  of  those  at  the  Invitational  Federal  Criteria  Workshop,  it  is  clear  that 
additional  work  needs  to  be  done  on  this  new  criteria  for  information  technology 
security.  The  Common  Criteria  Editorial  Board  (CCEB)  has  been  formed  to  develop 
a common  criteria  based  on  the  input  from  the  TCSEC,  ITSEC,  CTCPEC,  draft 
Federal  Criteria,  and  the  draft  ISO  standard  on  IT  Security  Criteria.  The  U.S. 
representatives  need  a complete  technical  proposal  that  represents  the  security  needs 
of  government  agencies  and  industry.  The  purpose  of  the  Federal  Criteria  project  is 
to  provide  this  proposal.  The  proposal  initially  will  consist  of  the  first  draft  of  the 
Federal  Criteria  and  the  contents  of  these  proceedings  from  the  Federal  Criteria 
Workshop.  As  time  passes,  drafts  of  the  U.S.  contribution  to  the  Common  Criteria 
incorporating  the  comments  will  be  provided.  The  Common  Criteria  will  undergo 
extensive  external  review  allowing  those  involved  in  the  original  Federal  Criteria 
project  (both  originators  and  reviewers)  to  continually  provide  valuable  data  to  this 
process. 


Major  Areas  of  Work 


The  first  draft  Federal  Criteria  motivated  over  20,000  comments.  There  were  some 
central  themes  in  these  comments  as  to  the  needed  direction  to  any  new  criteria, 
whether  it  be  a U.S.  Federal  Criteria  or  an  international  Common  Criteria.  These 
general  themes  were  confirmed  at  the  invitational  workshop.  The  result  is  the 
following  list  of  concepts  that  should  be  addressed  by  NIST  and  NS  A as  they 
contribute  to  the  CCEB  effort  to  develop  the  Common  Criteria,  progressing  rapidly 
toward  a truly  international  information  technology  criteria  standard. 
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Future  Work  with  the  Federal  Criteria  for  Input  into  the  Common  Criteria  Editorial 


1.  Fundamental  Security  Principles 

A section  needs  to  be  written  which  clarifies  the  security  principles  on  which  the  docu- 
ment is  based.  The  objectives  and  scope  of  the  document  need  to  be  clarified  as  well 

2.  Clarification  of  Security  Components 

The  components  presented  must  be  recast  in  language  that  is  easy  to  understand  for  the 
information  technology  expert  assembling  protection  profiles  and/or  security  targets.  In 
addition,  the  dependencies  must  be  clearly  stated.  Further,  the  components  must  be 
rewritten  to  be  evaluatable  and  usable  under  procurement  laws. 

3.  Completion  of  Underlying  Vetting,  Registration  and  Evaluation 
Concepts 

The  process  by  which  a protection  profile  is  reviewed,  accepted  and  registered  needs  to 
be  completed.  Similarly,  an  evaluation  process  which  uses  the  protection  profiles  must 
also  be  established,  complementing  the  development  of  the  Common  Criteria.  These 
two  processes  are  essential  so  that  both  criteria  and  product  developers  know  what 
requirements  to  build  to  and  how  the  resulting  product  will  be  assessed  in  relation  to 
those  requirements.  * 

4.  Preservation  of  Information  Technology  Security  Investment 

Attendees  clearly  and  strongly  emphasized  the  importance  of  preserving  industry 
investment  in  security  based  on  the  TCSEC,  not  necessarily  the  words  of  the  TCSEC. 
This  means  adequately  capturing  the  experience  of  the  past  ten  years  in  the  Trusted 
Product  Evaluation  Program  (TPEP).  The  components,  as  well  ^ die  protection 
profiles,  must  allow  for  all  current  implementations  of  the  trust  pnnciples  contained  in 
the  TCSEC,  its  formal  (and  informal)  interpretations,  and  its  evolution  through  the 
TTEP  process.  This  includes  concepts  such  as  Rating  Maintenance,  subsystems,  appli- 
cations (TDI)  and  network  components  (TNI). 

5.  Distributed  Security  Issues 

Information  technology  products  of  the  1990*s  are  commonly  designed  to  work  in  larger 
system  architectures  with  distributed  and  networking  services.  The  impact  of  security 
on  these  products  is  still  under  research.  This  research  will  provide  both  clarification  of 
known  concqits  in  light  of  distributed  issues  as  well  as  new  security  concepts  specific  to 
distributed  environments. 


Specific  Work  Area  Plans  in  Support  of  the  CCEB 


The  immediate  plans  must  focus  on  support  for  trie  Common  Criteria  Editorial  Board. 
This  means  focusing  resources  on  those  portions  of  the  Federal  Criteria  which  can 
provide  the  most  v^uable  initial  contribution  to  the  work  of  the  CCEB  along  with  the 
associated  comments  and  recommendations  on  those  portions.  Although  the  preferred 
method  would  be  to  complete  a version  of  the  Federal  Criteria  based  on  the  received 
comments  and  recommendations  from  the  invitational  workshop,  it  is  understood  that 
the  CCEB  carmot  wait  while  that  version  is  generated.  Therefore,  the  Federal  Criteria 
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Application  of  and  Response  to  Received  Comnients 


project  plans  to  provide  updates  on  appropriate  sections  when  they  are  needed  at  the 
CCEB. 

Application  of  and  Response  to  Received 
Comments 


The  comments  received  on  the  first  draft  of  the  Fedoal  Criteria  will  be  an  important 
source  of  information  for  the  NIST/NSA  contributions  to  the  Common  Criteria. 
Comments  received  will  be  used  to  make  the  necessary  changes  to  the  document  This 
includes  both  the  general  comments  discussed  here  and  the  specific  comments  on  the 
different  chapters  and  sections  of  the  Federal  Criteria.  It  is  planned  to  provide  commen- 
tators with  responses  to  comments  provided  once  the  resolution  to  them  is  known.  In 
addition,  commentators  will  be  placed  on  the  mailing  list  to  receive  the  draft  Common 
Criteria  for  public  review  and  ccmiment  when  it  becomes  available. 


Resources  to  Complete  the  Work 


The  bulk  of  the  work  defined  here  will  be  completed  by  NSA  and  NIST  personnel,  with 
input  from  contracted  infcHination  technology  experts.  However,  review  and  input  fi'om 
the  information  technology  industry  as  a whole  will  be  necessary  as  the  Common 
Criteria  development  process  proceeds.  It  is  understood  that  the  user  and  vendor 
community  will  remain  an  important  source  of  technical  informatiem  as  this  project 
continues. 


Summary 


The  draft  Federal  Criteria  made  a significant  contribution  to  the  field  of  information 
technology  security.  However,  it  was  a first  draft  and  substantial  work  would  be 
required  to  complete  the  Federal  Criteria.  Instead  of  expending  resources  directly  on 
this  effort,  NSA  and  NIST  will  focus  on  contributing  the  central  material  from  the 
Federal  Criteria,  augmented  by  the  incorporation  of  the  many  comments  and  recom- 
mendations made  on  it  by  the  commentators  of  the  draft,to  the  Common  Criteria  effort 
The  result  will  be  an  information  technology  security  criteria  with  an  international 
scope  that  will  meet  the  needs  of  both  U.S.  government  and  industrial  users. 
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APPENDIX  North  America  and 

Europe  Agree  to  Develop 
Common  Criteria 


Summary 


The  governments  of  North  American  and  European  nations  have  agreed  to  develop  a 
Common  Information  Technology  Security  Criteria*’  (CC).  Participants  include  the 
European  Community,  Canada,  and  the  United  States. 

Security  criteria  are  needed  to  develop  trusted  information  technology  (IT)  products  that 
can  be  used  to  help  protect  important  information  of  the  government  and  private  sectors. 
IT  security  criteria  common  to  Europe  and  North  Amoica  will  help  broaden  the  market 
for  these  products  and  further  lead  to  economies  of  scale.  In  addition,  common  criteria 
will  help  achieve  the  goal  of  mutual  recognition  by  North  American  and  European 
nations  of  IT  product  security  evaluations. 

The  effort,  which  is  expected  to  begin  in  early  Fall  of  1993  and  be  completed  in  the 
Spring  of  1994,  will  use  the  ISO  Subcommittee  27,  Wcxking  Group  3 draft  criteria 
documents  (Parts  1-3)  as  an  initial  framework.  Specific  inputs  will  include  the  Informa- 
tion Technology  Security  Evaluation  Criteria  (TTSEC),  the  Canadian  Trusted  Computer 
Product  Evaluation  Criteria  (CTCPEC),  the  draft  Federal  Criteria  for  Information  Tech- 
nology Security  (PC),  the  experience  gained  to  date  with  the  ITSEC  in  the  form  of 
suggested  improvements,  the  comments  now  being  received  on  the  draft  FC  document, 
and  the  results  of  the  FC  invitational  workshop  planned  for  2-3  June  1993. 

The  resulting  common  criteria  are  expected  to  undergo  extensive  international  review 
and  testing  by  performing  evaluations  of ’^real”  products  against  the  criteria  prior  to 
being  fully  accepted  for  use  within  Europe  and  North  America.  When  mature  enough, 
the  CC  will  be  provided  as  a conuibution  towards  an  international  standard  to  ISO 
Subcommittee  27,  Working  Group  3. 
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Background 


The  agreement  grew  out  of  a 4 February  CEC-sponsored  workshop  in  Brussels  on  the 
Federal  Criteria  that  was  attended  by  many  European  security  professionals.  The 
general  European  response  to  the  workshop  was  that  alignment  of  criteria  between 
Europe  and  North  America  is  now  both  feasible  and  opportune. 

This  idea  was  taken  up  and  endorsed  by  the  EC  Senior  Officials  Group  for  the  Security 
of  Infcmnation  Systems  (SOG-IS)  in  their  meeting  on  11  February,  clearing  the  way  for 
EC  participation  in  the  work  required  to  achieve  common  IT  security  criteria. 

As  a result  of  informal  meetings  held  thereafter,  a proposal  was  made  to  proceed  with  a 
joint  project  to  develop  common  criteria.  This  proposal  was  then  given  preUniinary 
approval  by  EC  member  nations  and  North  American  government  senior  officials. 


Planned  Development  Procedure  - The  Editorial 
Board 


Current  plans  call  for  the  establishment  of  a six  member  Editorial  Board  (EB)  consisting 
of  three  members  from  North  America  and  three  from  Europe.  The  EB  will  be 
composed  of  senior  IT  security  experts  who  have  had  experience  designing  IT  security 
criteria  and  have  the  authority  and  autonomy  to  make  decisions  with  regard  to  the 
contents  of  the  CC.  The  EB  will  be  requested  to  complete  their  work  within  a six  month 
timeframe.  The  main  tasks  of  the  EB  are  to  obtain  a clear  understanding  of  the  similari- 
ties and  differences  between  current  criteria  and  to  develop  v-  first-draft  CC  for  presenta- 
tion to  the  participating  government  bodies.  The  EB  will  bt  ir^soiicted  to  use  the 
material  identified  above  as  the  primary  material  from  which  to  develop  the  CC.  The  CC 
is  to  iqnesent  a synthesis  of  the  best  concepts  and  components  contained  in  the  original 
material.  The  EB  is  to  avoid  inventing  new  criteria. 


Technical  Groups  to  Pt  ovide  Support 


The  EB  may  establish  and  utilize  special  Technical  Groups  (TGs),  as  needed,  to  help 
develop  q)ecific  technical  areas  of  the  CC.  These  TGs  will  operate  under  the  direction 
of  the  EB  for  the  time  needed  to  perform  their  assigned  tasks.  They  will  be  staffed  in  a 
iqiresentative  way,  in  a pattern  like  that  of  the  EB. 

Public  Review  and  Trial  Use 


Flowing  completion  of  the  first  draft  criteria,  the  governments  involved  will  jointly 
review  the  CC.  When  they  mutually  determine  that  the  CC  is  ready  for  further  review  by 
the  n security  community  at  large,  they  will  initiate  an  extensive  review  cycle  to  obtain 
comments  from  all  interested  parties.  This  cycle  is  e^qrected  to  result  in  additional 
versions  until  convergence  is  achieved.  The  CC  will  then  enter  a trial  period  to  allow  the 
q)ecificaiion  and  evaluation  of  vendor  offerings  against  the  CC.  Upon  completion  of  the 
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Rslationship  to  ISO  International  Standardization 


trial  period,  the  CC  will  be  revised  if  necessary  to  gain  final  adoption  by  the  partici- 
pating governments. 


Relationship  to  ISO  International  Standardization 


During  the  process  of  CC  development  and  trial  use,  the  associated  governments  will 
woric  through  their  respective  national  standards  bodies  to  help  keep  the  ISO  draft  stan- 
dard in  relative  synchronization  with  the  CC.  An  issue  requiring  further  study  and 
consultation  is  how  to  maintain  the  necessary  level  of  momentum  in  ISO,  yet  avoid 
finalization  of  an  International  Standard  prior  to  achieving  generally  accq)table 
conunon  criteria  for  Europe  and  North  America 
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